Comments on: “Bus” for Bus

By: kamstrup

kamstrup — Sat, 20 Mar 2010 22:35:12 +0000

@Anders: TO be honest – I don’t know. I’d actually expect that something more in spirit of a HTTP proxy would more suitable than a full blown server. Web servers do quite a lot more than parse HTTP headers. If we primarily want to use it for local messaging and at times as a message-bridge to the web, then something akin to a light proxy server might be enough.

By: Anders Feder

Anders Feder — Sat, 20 Mar 2010 18:32:43 +0000

@kamstrup: I see. Is this not what Cherokee and other ‘light’ webserver projects are trying to achieve? Perhaps they are not focused exclusively on the desktop..

If only I had time in between talking out of my ass, I’d do something about it

By: kamstrup

kamstrup — Sat, 20 Mar 2010 13:53:08 +0000

@Anders: Well – the raw DBus protocol is pretty efficient, by design, compared to HTTP. One can indeed write a light, extremely efficient, HTTP server intended for desktop – not server use, That may outperform DBus, since afaik the dbus-daemon has not been optimized a lot.

But if we keep the question to “Can we write a light, efficient, HTTP server for the desktop”, then the answer is undoubtedly “yes”. But if we really really want to make it light and efficient then it’ll take a lot of work. The question is much harder when we want to compare it to DBus

By: Anders Feder

Anders Feder — Fri, 19 Mar 2010 22:07:54 +0000

jamie: HTTP for local IPC doesn’t sound very efficient? I imagine a lot of overhead compared to D-Bus? Or am I just being prejudiced?

By: blankthemuffin

blankthemuffin — Fri, 19 Mar 2010 12:19:53 +0000

God I hope web apps don’t take over. I hate web development so much. Personally I don’t see why people seem so keen to integrate technologies like css into the desktop, I mean really? css? It’s a freakin pain in the ass. There are good reasons for all these high level wrappers of css, and they all orient around it being trashy. We need to take a harder look at these problems I think, rather than deciding on half baked solutions because they already exist.

End web development / css rant.

By: kamstrup

kamstrup — Fri, 19 Mar 2010 07:28:16 +0000

@Jamie: “EG take the concept of first class objects like a contact or person and it should be clear that only a web service could represent such an entity” – why? This seems perfectly doable over DBus. We’d have to escape the RPC-shackles we have put on our selves – but that’s not a big issue. Simply say that fx. contacts are represented by objects with path /org/gnome/contacts/ – no mention of bus name or interface, simply use DBus match rules to interact with it.

And “Web services can have life cycles too” – what apart from a login has state in web services? Is rule number uno of web services not that they should never have state?

Anyway if you want to use web services as a bus-like thing you have to keep connections open to them so they can signal you and what not. Otherwise the webservices would need a boatload of state so that you could do active polling on them. Both options sounds like a steep price on system resources..?

By: Jamie

Jamie — Thu, 18 Mar 2010 23:23:56 +0000

@kamstrup: whilst web apps are undoubtedly the future, I still reckon web services should replace the session dbus if only because it makes more sense in a cloud oriented environment. DBus will certianly live on as the system bus for the kernel/X/hardware but its role as a sesison bus in apps will likely be marginalised by a desire to integrate more with the cloud (prior to the emergence of a web app based future)

EG take the concept of first class objects like a contact or person and it should be clear that only a web service could represent such an entity wherever it be (be it local or on the cloud).

Web services can have life cycles too and a web service/dbus session bridge is something that would make a lot of sense too IMO

By: kamstrup

kamstrup — Thu, 18 Mar 2010 22:46:09 +0000

@Jamie: If you mean that all apps are webapps running in a browser, then indeed DBus will not play a big role. However let us not forget that DBus is used in stuff like X and Upstart as well. I also have a hard time seeing webapps completely taking over for at least 5-10 years.

The lack of null support is a bitch I give you that. However let’s see what happens when GVariant goes more mainstream. It’s support for maybe-types could eventually lead to introduction of the same concept in the DBus wie format.

DBus also have the huge advantage over HTTP that it is a bus (and a life cycle manager).

Regarding functional languages I’d hate to start that flamewar However I am also more keen on emphasizing that cross breed languages like F# and Scala (and to some degree Vala) are more likely to win followers than purely functional ones imho. But it also depends on which frameworks there are for these runtimes. That said I still think there is a wonderful mathematical beauty in purely functional languages.

By: Jamie

Jamie — Thu, 18 Mar 2010 21:02:59 +0000

DBus is old hat – all the cool kids now use web services instead. I’ll wager that with increasing use of the cloud (and therefore the need to interact with both local and cloud) that web services will likely replace the olde bus in the not so distant future. HTML 5 will use it too so and that could replace GTK/QT if done right. i also feel dbus has some technical shortcomings (no null value support, no enums etc)

Functional languages are really old and are serious old hat and difficult to maintain projects written in them. With the need to support threads safely and sanely async message passing will be retained behind the scenes but the front of any language will likely remain procedural (with the odd lambda syntax) although with vala style sugar masking the message handling