Why would you want to pipe D-Bus through HTTP? Having developed the cups print backed for GTK+ I can say I am done with any protocol that uses HTTP as a transport layer. It is mainly used to transparently punch holes through firewalls which isn’t a terribly convincing argument as those firewall rules are there for a reason.

What do you mean by “the remote part”? Letting the server do something D-Bus-y?

My own work was more focused on using HTTP as a DBus transport; perhaps I will dust it off again. Given that I was thinking of such drastically different use cases, I’ll be very interested ot see what people cook up with this solution.

Let me address both issues briefly:

1. by crafting API that is meant to be web accessible it would mean a traditional desktop developer could integrate a thick app more readily with online content blurring the lines between the web and the desktop. Think of it as plugins without the plugin running in the browser. This would have to require security profiles like we have for the system bus. For example by giving access to the notification daemon for a certain trusted site, lets say google mail, it could send notifications that mail has been received or someone it trying to im you. Right now if someone im’s me I only see it when I go to the browser window running g-mail which I tend to keep open but hidden all day.

2) Services pop on and off the bus all the time. Autostarting them isn’t really helpful here but if D-Bus API were available on a certain site, I might want to integrate. It is like XMLRPC except with notification when a service is currently being browsed and using an API that a lot of desktop users are familiar with. Look at flicker uploads in F-Spot – that is all done using web transports but what if we had D-Bus service and a standard interface for uploading to image sites? If I were browsing an image site, an app might keep track of URL’s it saw implementing that interface and automatically be able to utilize it.

Again a lot of this stuff could be done with current technologies (much like you could do the same things with Corba or DCOP on the desktop) but D-Bus lowers the bar to entry so that creating interactive rich experiences between the web and the client becomes the norm, not the exception. Security does have to be thought about of course which is why I was originally worried about the D-Bus bridge since no one had seemed to talk about the design on the D-Bus list. Seeing that it is a tool for creating local apps alleviates those worries but then also makes the bridge much less useful since I can do similar things with or without a browser using the GLib JavaScript bindings. It is pretty cool though and something to make creating integrated desktop/mobile apps by traditional web programmers. I guess I’m more looking for something the other way around – how to bring traditional desktop programmers to integrating with the web.

1. Remote site access to DBus

Given the current abundance of malicious code trying to poke through the browser as is, giving *more* opportunities to trash around doesn’t seem attractive. How could you trust the other end? Sertificate-based security is not working for the general case, and authenticating the user doesn’t help trusting the remote end. The vision of UI loaded from operator site is naturally in the picture, but that’s more per-use-case I think…

2. Creating services through the Bridge

I’m having a hard time coming up with a compelling use-case for this (that’s why it’s not high on the TODO list…). The lifetime of a JS context in a browser page is fickle at best, you don’t really want to have a service bouncing on and off (not to mention that autostarting it would be rather interesting). Most use-cases that we have come up with can easily be done with what support there is now. But if you really want to write a service with JS, I think things like Seed and GJS are a better way to do that.

The code is available here if anyone is interested:
http://github.com/FireRabbit/mozjs-dbus/wikis