A Desktop That Will End The Desktop Wars

Posted 19 Jan 2004 at 06:03 UTC by nymia Share This

The problem why there are so many battles and wars on the desktop is primarily due to lack of standards. Most of the desktop models rolled-out nowadays contain vendor specific implementation that is usable within the vendor definition. As a result, no interconnection between dissimilar environments (brandwise) exists. One can see some interfaces that work while others are only available on one, missing on another.

To address this issue, a standard desktop interface definition is required. The W3C.org has a set of DOM interfacces [1] that can used to build the Desktop Interface (DI). New desktop related interfaces can be added on top.

In effect, vendors will have a guide on what the standard interfaces are and from thereon add their own specific features called 'value adding.'

Below is a sample interface definition. 

interface HTMLDesktop : Desktop {
           attribute  DOMString            title;
  readonly attribute  DOMString            referrer;
  readonly attribute  DOMString            domain;
  readonly attribute  DOMString            URL;
           attribute  DesktopElement          body;
           attribute  DesktopElement          desktopBar;
  readonly attribute  DesktopCollection       images;
  readonly attribute  DesktopCollection       applets;
  readonly attribute  DesktopCollection       links;
  readonly attribute  DesktopCollection       forms;
  readonly attribute  DesktopCollection       anchors;
  readonly attribute  DesktopCollection       applicationIcons;
  readonly attribute  DesktopCollection       menus;
  attribute  DOMString            cookie;
  void                      open();
  void                      close();
  void                      write(in DOMString text);
  void                      writeln(in DOMString text);
  Element                   getElementById(in DOMString elementId);
  NodeList                  getElementsByName(in DOMString elementName);
};


Once a set of desktop interface is ratified, these so-called wars on the desktop will subside, even disappear entirely.

Wishful thinking..., posted 19 Jan 2004 at 13:50 UTC by pphaneuf » (Journeyer)

That last sentence is where it completely breaks down.

But I wish it was true too. Heck, they could use XPLC to implement this, so that you'd have interface discovery (for finding the "value adding").

Hmmm, posted 20 Jan 2004 at 10:30 UTC by Malx » (Journeyer)

Until "add their own specific features" is possible there whould not be any good of such standart :)

You could add only one feature or 300% of new features and it will break all.

And the meaning of "The Desktop Wars" are not about standart. They are about sale and development.

Eh?, posted 20 Jan 2004 at 14:48 UTC by elanthis » (Journeyer)

What exactly are you trying to solve again? The Desktop these days has more standards than you can shake a stick at, thanks to FreeDesktop.org.

The Desktop Wars, as they're called, are almost entirely a thing of *design*. I.e., do you prefer the bloated and ad-hoc KDE design, or the clean and elegant GNOME design? (Ya, you can tell which camp I'm with, yes? ~,^ )

The interoperability issues between KDE, GNOME, Rox, XFCE, GNUStep, etc. are all being solved. The design issue is much more important, however - I'd rather not have "Random Applet" at all than have one which has the KDE look and feel to it on my GNOME desktop, as that design feels so alien on my system.

A standardized HIG would do a lot more for users than any kind of DOM-ish API ever would. Again, however, seeing as KDE and GNOME have some very different philosophies, I doubt any such HIG would ever exist, as it would mean changing not only opinions but also taste in various ways for both parties. (Not to mention the various design choices from the other Free desktops out there.)

Drum Beating Time, posted 21 Jan 2004 at 04:03 UTC by nymia » (Master)

The Desktop Interface is simply a specification. Implementation is left entirely on the vendor or project. It can be implemented in any language: C, C++, Java, C#, etc.

There are numerous benefits of having a Standard Desktop Interface (SDI), one is having the ability to reference them as objects inside an interpreted language. A sample code shown below demonstrate the potential. 

   var MyTaskBar = New MyDesktopBar();
   desktop.document.taskBar = MyTaskBar;
   MyTaskBar.show;


The illustrious pphaneuf raised a good point and I agree to certain extent right before the wishful thinking part. Although there is strong possibility a well-respected org will bring it to fruition.

Also, my comrade Malx, adding features are allowed and are strongly encouraged, provided the implementation follows the interface. You are correct to say the possibility of having a broken implementation, vendors have the tendency of breaking interfaces and I won't name them here. Desktop Wars exist because incompatible implementations fight in one environment. The result: a cornucopia of apps with varying degrees of vendor specific API extensions.

Honorable elanthis, the goal is to minimize maverics who enter and break rolled-out APIs, which is so rampant. Both Gnome(G) and KDE(K) have demonstrated the possibility of creating a standard interface and are working towards a unification--in the interface layer--which will (I hope) be much better than what we have at the moment. Not to steal your words, but I think you have point too.

application communication, posted 21 Jan 2004 at 19:37 UTC by lkcl » (Master)

interfaces are good. i love interfaces: especially open ones.

issue: your definition of an interface doesn't include a communications mechanism.

e.g. COM, DCE/RPC, DCOM, Corba, SOAP (yuk) notDET, other.

if the interface is unspecified, it is necessary to define intermediary communications / translation mechanisms between the people who begin to implement the interface.

e.g. if someone implements a python interface and it's in, horror of horrors, XMLRPC (which was the XMLRPC author's way of "stepping up" a learning curve towards SOAP, and XMLRPC should never have seen the light of day. *sigh*) and some other person implements a perl interface and it's in.. mmm... SOAP, and the desktop actually runs as a DCE/RPC application, then it is necessary to have a communications shim service that fronts both XMLRPC and SOAP and makes calls via DCE/RPC to the actual desktop.

it's actually quite straightforward.

[btw for those people who may not be aware of it, COM plus DCE/RPC equals DCOM. or, more specifically, DCOM minus the remote bit of DCE/RPC equals COM, where COM was done solely for windows 95 because there was no way that the NT team could let the windows 95 team anywhere near the export-restricted security/authentication code in the NT implementation of DCE/RPC.]

communication mechanism, posted 23 Jan 2004 at 21:11 UTC by pphaneuf » (Journeyer)

XPLC is a bit like COM, save for the communication part, so you need that even more, as lkcl said.

But I'd point out that almost all the mechanisms he mentioned are RPC-oriented, and the general feeling (including from Microsoft, who used to push about half of those he mentions) is that RPC-oriented (sometimes called "remoting") is "out" and message-oriented (sometimes called "messaging") in "in". For example, Microsoft now pushes Indigo instead, which is mostly based on messaging.

I'm not too up to speed on what's the message-oriented communication situation in open source, but I hear D-Bus is good.

Common understanding is key, posted 4 Feb 2004 at 07:01 UTC by nymia » (Master)

Having a common level of understanding is probably the best step to take, simply because it places the focus in one place. Projects or groups involved in any desktop related work could in theory talk in a language void of implementation. A language good enough to store such abstract items can easily be described and communicated to others who are only interested not in how these abstract items will take shape, engaging in discussions as to how said abstract items can be modified and extended.

Take for example, communicating abstract desktop items in the forums of fd.o will improve considerably if a set of common abstract items are defined initially. A knowledge base may be created for record keeping, tracking the progress.

The main thing to remember is to not mention any specific implementation because implementations should only be covered only after a common set of abstract items are defined and ratified.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page