Wed 12 Nov 2008
They have the details up on their web site. Apparently it is a way of creating local applications using either Gecko or WebKit. The remote part of the equation isn’t there and it isn’t clear if they will be perusing this angle. Right now the code only supports clients but by the look of their documentation, they are planning on creating the ability for JavaScript services which would be cool.
November 12th, 2008 at 5:22 pm
A while ago I started a similar project. Unfortunately, I was never able to take it anywhere.
The code is available here if anyone is interested:
http://github.com/FireRabbit/mozjs-dbus/wikis
November 14th, 2008 at 3:30 am
Since you brought them up, I’d like to hear if your thoughts about the following:
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.
November 14th, 2008 at 4:33 am
Hi Kalle,
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.
November 18th, 2008 at 5:14 pm
As per my comments on your previous post on this topic [ http://www.j5live.com/2008/09/30/apparently-gnome-mobile-has-a-d-busbrowser-bridge/ ] I’m glad there’s finally source.
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.
November 18th, 2008 at 6:41 pm
Remote and local in the browser can be thought of as the same thing except for security implications. If you install an app locally you have implicitly granted it access to anything on your desktop. You however do not want a remote app with those privileges since it is too easy to run a remote app that might be harmful but in essence they could be the same exact application (note that in order for an app to be local in a browser it has to be installed into the browser – files served up by the filesystem are still considered remote). So by enabling D-Bus for remote apps you allow them to set up service or read certain restricted data from the machine. This requires a well thought out security model but would also be extremely useful in melding the desktop and the web.
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.