Re: D-Bus AFL/GPL issues (was Re: GLib plans for the next cycle)
Hi, On Fri, Apr 24, 2009 at 6:56 AM, Simon McVittie wrote: > As mentioned above, dropping my use of libdbus' "helpful" object path mapping > and just using a filter function was a net code reduction. Getting pretty off-topic, but the object path mapping in DBusConnection isn't intended to be a convenience/helpful thing. The purpose of it is to ensure that introspection includes objects registered by all bindings in the process. So say for example gvfs exports an object, or libunique exports an object; and then some python code exports an object; Introspect() needs to merge all those nodes and return a single list of nodes. The other possible solution is that every binding has its own private socket (appears to be a separate app on the bus), which is kind of fine, but a little bloated/weird. With a private DBusConnection there is no real reason to use the object path registration. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: D-Bus AFL/GPL issues (was Re: GLib plans for the next cycle)
On Thu, 23 Apr 2009 at 21:11:13 +0100, Robert McQueen wrote:
> dbus-python has had to duplicate a lot of the checking that libdbus does
> to validate calls before calling methods in libdbus, because whilst
> libdbus requires the application programmer gets stuff right at all
> times, dbus-python can be tricked by the python programmer into causing
> libdbus to abort. These checks are not in general exported as public
> API, and even with many checks in the Python code, its still possible
> for the Python programmer to assert libdbus from Python code in various
> corner cases.
Various libdbus functions will (default-fatally) warn if you pass them an
invalid object path or bus name, but libdbus doesn't give you a way to check
whether a Python-programmer-supplied string is a valid object path. Yes, this
is programmer error, but it's programmer error that, in Python, should be
reported in the Python way, by raising ValueError.
In both dbus-python and telepathy-glib, I've ended up implementing a set of
functions that raise an appropriate language-specific exception (an Exception
or GError respectively) if an object path/bus name/error name is bad. I'd be
happy to place either of these under the MIT/X11 license proposed for libdbus
(indeed, the Python one is already under that license) if anyone is interested
in porting them to raise DBusError.
On the other hand, because of libdbus' privileged roles as "the implementation
of dbus-daemon" and "a library from the dbus-daemon source package",
having a hard dependency on a newer libdbus is not necessarily a decision to
be taken lightly. Backporting a mere library like dbus-glib or dbus-python
is easy, but backporting dbus-daemon to an older distribution is less popular.
If nothing else, because (as its maintainers are so keen to remind us) the
system bus is a Critical System Service, correctly installing a new
dbus-daemon requires either a reboot, or a risky and discouraged system bus
restart, neither of which is a desirable action.
> There are silly cases like half way through packing a struct where the
> application has provided the D-Bus type, but later a value that doesn't
> fit that type. You can't close the struct because you'll abort libdbus.
> Unless you implement two-pass validation and check the types before
> building the message, there's no way out of this other than to fill the
> struct with nonsenense, /then/ close the iter, /then/ discard the
> message. If it was Python code you could just throw an exception back to
> the app author and get on with life.
dbus-python does suffer from this. It does throw exceptions wherever needed,
but I haven't had the spare time to implement either two-pass validation or
the "fill the struct with zeroes" unwinding, meaning that passing {'foo': None}
to a D-Bus method that takes an a{sv} or a{ss} will either warn to stderr then
throw an appropriate exception anyway (in Debian-derived distros where
libdbus has been patched to have non-fatal warnings by default), or just abort
(in e.g. Fedora).
> Further to this, the OOM stuff is simply not of interest to (m)any other
> apps other than the daemon and the X server, and indeed if you write a
> D-Bus implementation in your native language/VM/style then you almost
> certainly get this for free, rather than wiring it up every other line
> of code.
Right, in GLib you conventionally just abort on OOM, and in Python you raise
MemoryError (which is easier than it sounds, because in the CPython API,
basically anything is allowed to raise an exception - so CPython programmers
already have to deal with them - and in Python, exceptions are syntactically
special in the expected way).
> It seems that if you're not using libdbus directly, or you're not the
> bus daemon, its a pretty hostile library to write bindings with,
> especially if the language is dynamically typed. People hacking on both
> bindings at Collabora have lost hair and screamed and sworn they would
> rewrite them to not use libdbus given half a chance, and I honestly
> don't think we're alone in this sentiment.
dbus-python has a branch called 'purity' (as in "pure Python") which I've never
dared to merge; it stops using libdbus' object-path-registration mechanism
entirely, and catches method calls by using a filter instead. This was, perhaps
unexpectedly, a significant code reduction, because I no longer had to keep
a separate registry of objects in dbus-python (in order to be able to raise an
exception on double-registration rather than letting libdbus abort me).
(It also fixed an isolated piece of OOM misbehaviour in which dbus-python would
exacerbate an OOM at precisely the wrong time by leaking a string, because
there was nothing else I could safely do; see the source code if interested.)
If I'd had time to continue on that path, the next step was going to be to use
dbus_message_[un]marshal() to get the binary blob containing the message
payload and parse it into Python data structures myself rather th
Re: D-Bus AFL/GPL issues (was Re: GLib plans for the next cycle)
On Thu, Apr 23, 2009 at 6:24 PM, Robert McQueen wrote: > Havoc Pennington wrote: >> >> Nobody has yet explained (to my satisfaction anyway) how the libdbus >> license has an issue the LGPL does not have. Perhaps we should get >> Luis or SFLC on the case, but I'm not sure it's worth their time. > > My belief is that the problem is that under certain implementations of > LGPL, the stuff you link the LGPL library to must also be LGPL > compatible, and that the AFL patent clause is not. The alternative > interpretation is therefore that you make your LGPL code GPL, and take > libdbus under the GPL, but this is unacceptable for a proprietary > application which cannot link GPL libraries. IANAL etc. This issue was once described to me having to involve multiple applications linking to libdbus: * (L)GPL application is incompatible with AFL so libdbus falls under GPL (as does the application) * proprietary application is incompatible with GPL so libdbus falls under AFL Now as long as you're not mixing (L)GPL and proprietary applications all is fine. However once you mix both you get a system where dbus license can't satisfy both cases. The argument being that dbus as distributed/running on a system can have only one license, not "GPL when used from app A, but AFL when the same library/daemon is used from app B" Then again, the system library exception would allow dbus to be AFL while remaining (L)GPL compatible. -- Tommi Komulainen tommi.komulai...@iki.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: D-Bus AFL/GPL issues (was Re: GLib plans for the next cycle)
Havoc Pennington wrote: > Hi, > > On Thu, Apr 23, 2009 at 1:24 PM, Robert McQueen > wrote: >> My belief is that the problem is that under certain implementations >> of LGPL, the stuff you link the LGPL library to must also be LGPL >> compatible, and that the AFL patent clause is not. > > This doesn't make much sense to me (the whole point of LGPL over GPL > is that there isn't a compatibility thing; LGPL should not > "contaminate" and require AFL to change). The LGPL makes a clear distinction for a "work that uses the Library" and allows all manner of things which the GPL does not. Other than that, the terms of the LGPL are broadly similar to those of the GPL. In the case of an LGPL library that relies on libdbus to do its job, libdbus is definitely /not/ a work that uses the library. In their definition of a derivative work, they say that you are allowed to rely on external functions or lookup tables, but that if they are missing, the library must still operate and its purpose remain meaningful. In the case of EggDBus (or telepathy-glib), the library is rendered totally useless by the lack of libdbus, so I think this doesn't count. So - if you're linking libdbus into Glib and distributing the result as LGPL, you could be violating the GPL-incompatible terms of the AFL which require additional actions that the LGPL does not. It's not open and shut by any stretch of the imagination, and furthermore I'm not even certain that this is even the line of reasoning behind our clients' concerns. However, I'm not a lawyer, but have definitely have come across clients (who have presumably asked their lawyers) who have decided this combination of LGPL + GPL/AFL is unsound. Hence I'd like to better understand their rationale and check with our own lawyers before dismissing it. >> Yes, this is handwavy and I'm not sure what I'm talking about, but >> I'm sure of one thing: I have run into clients who due to this >> issue have either a) applied a handwavy "system library" defence >> for this problem, > > Not sure system library is handwavy... the GPL is (relatively) clear > on the system library point. However, the problem with system > library exception is the text "unless that component itself > accompanies the executable" i.e. it can't be used by someone shipping > both the app and the library. Yeah, that's why I said it was a handwave in the context. :) >> * seeking legal advice from Collabora's advisors on whether the >> above is a genuine issue, or what other concerns might be >> * endeavouring to find out from our would-be clients above what their >> specific concern was >> * trying to track down the Codefactory code (again) so we can actually >> complete the license change and move on with our lives > > Certainly seems sensible to ask what people are worried about. Note, > there was a lot of uproar about AFL 1.0 patent clause, but we aren't > using that, this is AFL 2.1. I don't think AFL 2.1 requires anything > more than LGPL/GPL, with respect to patents. And I think AFL phrases > the requirements in a clearer way than LGPL/GPL. The AFL (all versions through v3.0) is incompatible with the GPL according to the FSF due to requiring distributors to seek the assent of the recipient: http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses http://opensource.org/licenses/academic.php (clause 9) >> Pending the outcome of my enquiries, if if *is* a real concern, and >> we're unable to find where the Codefactory stuff really resides, >> I'd much rather get someone at Collabora to rewrite the code than >> handwave and pretend its fine. > > Certainly open to this, if anyone wants to invest the effort. If it proves necessary, I think we'll try and do this. In the case of dbus-glib and the daemon itself, there's quite a lot of code there, but in the restricted case of libdbus (assuming EggDBus) it seems more tractable. We can just port telepathy-glib to sit atop EggDBus then (hopefully very thinly), and be shot of the problem after an ABI bump. >> (Its not an unthinkable amount of code, though of course if the >> effort to rewrite it is more than the effort to port EggDBus to >> GVariant/GBus, that might make more sense anyway. Although now Qt >> is LGPL rather than GPL+proprietary, they now have the same >> potential issue.) > > Not to go on a tangent, but I think there's real value to a shared > "least common denominator" implementation of dbus. >>> stop reading here if you just care about the legal issue <<< This /is/ a big tangent. :) I'll bite and try and give you a little more understanding based on the past few years at Collabora, but don't be too offended if I'm not able to reply much beyond this, as I'm pretty busy at the moment. > One of the big reasons is precisely the protocol extensions people > are talking about. e.g. the "protocol v2" work in gbus/gvariant; it's > great and all, but basically useless because dbus-daemon does not > speak this new protocol
D-Bus AFL/GPL issues (was Re: GLib plans for the next cycle)
Havoc Pennington wrote: > Hi, Hi Havoc, > Just for the record, my comment on this has always been that the > license issues were not earth-shattering to begin with, and the > relicensing was just throwing a bone to people who cared. Not sure > "large chunk" is super accurate, either. As a practical matter this > topic is highly overblown. > > Nobody has yet explained (to my satisfaction anyway) how the libdbus > license has an issue the LGPL does not have. Perhaps we should get > Luis or SFLC on the case, but I'm not sure it's worth their time. My belief is that the problem is that under certain implementations of LGPL, the stuff you link the LGPL library to must also be LGPL compatible, and that the AFL patent clause is not. The alternative interpretation is therefore that you make your LGPL code GPL, and take libdbus under the GPL, but this is unacceptable for a proprietary application which cannot link GPL libraries. Yes, this is handwavy and I'm not sure what I'm talking about, but I'm sure of one thing: I have run into clients who due to this issue have either a) applied a handwavy "system library" defence for this problem, b) adjusted their software architecture to have a GPL isolation daemon with an additional IPC hop, or c) refused to consider our software (Telepathy) for this reason. So this possibly overblown / hypothetical legal issue is still a genuine cause for concern (and hence time/effort/money/perceived risk) for our clients, and therefore a concrete commercial issue for Collabora, hence my reluctance to just handwave it away like you if we're pushing it into Glib itself. I'd like to see it sorted out, so I'm doing the following: * seeking legal advice from Collabora's advisors on whether the above is a genuine issue, or what other concerns might be * endeavouring to find out from our would-be clients above what their specific concern was * trying to track down the Codefactory code (again) so we can actually complete the license change and move on with our lives > http://log.ometer.com/2007-07.html#17.2 > btw, I believe we were going to add a notice to COPYING in libdbus to > the effect of "all new code is also MIT/X11, and most code is MIT/X11, > but a few bits are GPL/AFL" so that new contributions are MIT/X11 and > we don't have to redo the relicensing mass email if we ever solve the > codefactory code. It doesn't look like this has been done, however. I'd appreciate if this could be done (if it hasn't already). Meanwhile, I'm going to try again to track down the Codefactory stuff, and ideally we can relicense it and be done with the whole issue. If anyone has any information they believe would be helpful for my quest, I'd appreciate that too. Pending the outcome of my enquiries, if if *is* a real concern, and we're unable to find where the Codefactory stuff really resides, I'd much rather get someone at Collabora to rewrite the code than handwave and pretend its fine. (Its not an unthinkable amount of code, though of course if the effort to rewrite it is more than the effort to port EggDBus to GVariant/GBus, that might make more sense anyway. Although now Qt is LGPL rather than GPL+proprietary, they now have the same potential issue.) >From a commercial perspective for Collabora, our clients choosing not to use our software for even what we consider fairly hypothetical/unlikely legal issues is still a real issue. Extending this to every consumer/reseller of the GNOME platform seems a pretty poor idea. For everyone else, my nightmare scenario is that this code /is/ acquired by some SCO-like copyright/licensing troll who starts trying to sue our clients for using GNOME and D-Bus based technologies. I'll report my progress on any fronts back to the list. > Havoc Regards, Rob -- Robert McQueen +44 7876 562 564 Director, Collabora Ltd. http://www.collabora.co.uk ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Tue, 2009-04-21 at 11:38 -0700, Brian J. Tarricone wrote: > Alexander Larsson wrote: > > It just feels like you want to have a cake (non-local file i/o) and not > > pay for it (supply dependencies). > > No, he just wants a sane default implementation. If the CUPS backend > isn't compiled, the print dialog still comes up, and you can at least > print to a file. A dialog that presents "Operation not supported" to > the user is pretty poor, IMO. As Allin suggested, it would be nice if > there was at least a default fallback implementation that tries the > BROWSER env var, and if that doesn't work, tries a list of known browser > binary names until one succeeds. You only get "operation not supported" when you're trying to access a non-local file. The default implementation handles all local files and file types. I don't see this as not sane. However, sure we could select a few uri types and add special case things like looking at env vars. I wouldn't mind a patch for this, but its hardly a major thing. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Tue, 21 Apr 2009, Havoc Pennington wrote: > On Mon, Apr 20, 2009 at 10:31 PM, Allin Cottrell wrote: > > IANAL, but... Hypothesis: Monster Corp distributes D-BUS under > > AFL, while believing that DB in fact violates patents held by > > Monster Corp. �MC then sues users of DB. �MC can no longer > > distribute DB under AFL, but they don't care! �They have succeeded > > in causing trouble. �But as Havoc says, if Monster Corp had > > distributed DB under *GPL they would have effectively made a > > patent grant and given up the right to sue, making this scenario > > impossible. > > Yes, you're right that the AFL imposes fewer restrictions than > GPL, just as any other MIT/X11 type of license imposes less > restrictions than GPL... > You aren't saying anything here that doesn't also apply to > libX11. OK, that's a fair point. -- Allin Cottrell Department of Economics Wake Forest University ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Alexander Larsson wrote: On Mon, 2009-04-20 at 18:45 -0400, Allin Cottrell wrote: On Mon, 20 Apr 2009, Alexander Larsson wrote: gvfs needs a session bus, not a system bus, so you're falling back to a non-gvfs system. Thus no http support. >> OK, I suppose I can get this working on my own system, but my main point is: why does GTK include a function such as gtk_show_uri which depends on a big stack of unspecified stuff? At least this should be mentioned in the documentation. As I said before, up till very recently one has been able to rely on GTK functions "just working" so long as the compile-time dependencies are satisfied. Thats not totally true, there are optional dependencies in gtk+ before gvfs. Things like shared memory, cups backend, etc. But, all the gio calls *do* work even with gvfs totally absent. The only thing that doesn't work is things involving non-local files, and I don't understand how you expect that to ever work without depenencies. gtk_show_uri() for instance is an excellent function to use to launch the users default app to open a specific file, based on its mimetype. It just feels like you want to have a cake (non-local file i/o) and not pay for it (supply dependencies). No, he just wants a sane default implementation. If the CUPS backend isn't compiled, the print dialog still comes up, and you can at least print to a file. A dialog that presents "Operation not supported" to the user is pretty poor, IMO. As Allin suggested, it would be nice if there was at least a default fallback implementation that tries the BROWSER env var, and if that doesn't work, tries a list of known browser binary names until one succeeds. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 2009-04-20 at 18:45 -0400, Allin Cottrell wrote: > On Mon, 20 Apr 2009, Alexander Larsson wrote: > > > gvfs needs a session bus, not a system bus, so you're falling back to a > > non-gvfs system. Thus no http support. > > OK, I suppose I can get this working on my own system, but my main > point is: why does GTK include a function such as gtk_show_uri > which depends on a big stack of unspecified stuff? At least this > should be mentioned in the documentation. As I said before, up > till very recently one has been able to rely on GTK functions > "just working" so long as the compile-time dependencies are > satisfied. Thats not totally true, there are optional dependencies in gtk+ before gvfs. Things like shared memory, cups backend, etc. But, all the gio calls *do* work even with gvfs totally absent. The only thing that doesn't work is things involving non-local files, and I don't understand how you expect that to ever work without depenencies. gtk_show_uri() for instance is an excellent function to use to launch the users default app to open a specific file, based on its mimetype. It just feels like you want to have a cake (non-local file i/o) and not pay for it (supply dependencies). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Hi, On Mon, Apr 20, 2009 at 10:31 PM, Allin Cottrell wrote: > On Sun, 19 Apr 2009, Havoc Pennington wrote: >> The license was written by a lawyer and is perfectly sane. > > "Sane" and "written by a lawyer" are surely orthogonal to > desirability from the point of view of free software. The contrast is with things like the Artistic 1.0 license, which is a legal mess written by a non-lawyer. That is not desirable because the license ends up vague (from a legal perspective) and difficult to enforce in court. AFL was written by an open source advocate (and lawyer) with input from a lot of other open source people. The point is, it's not some off-the-wall license made up over beers. It was written by someone competent to do so and vetted by quite a few others. It is an "approved license" on opensource.org. > IANAL, but... Hypothesis: Monster Corp distributes D-BUS under > AFL, while believing that DB in fact violates patents held by > Monster Corp. MC then sues users of DB. MC can no longer > distribute DB under AFL, but they don't care! They have succeeded > in causing trouble. But as Havoc says, if Monster Corp had > distributed DB under *GPL they would have effectively made a > patent grant and given up the right to sue, making this scenario > impossible. Yes, you're right that the AFL imposes fewer restrictions than GPL, just as any other MIT/X11 type of license imposes less restrictions than GPL. > OK, maybe there's no Monster Corp associated with D-BUS right now, > but we know there _are_ such monsters around. This seems to me a > _major_ reason to see *GPL as superior to AFL from the p.o.v. of > free software. The discussion is not about whether AFL (or MIT/X11 type licenses in general) are superior to GPL-type licenses philosophically. The discussion is about whether there's a licensing "problem" with libdbus that keeps GLib and GTK+ from relying on it. Last I checked, GTK+ at least linked to quite a bit of code under MIT/X11 sort of licenses, such as libX11. You aren't saying anything here that doesn't also apply to libX11. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Sun, 19 Apr 2009, Havoc Pennington wrote: > I think my arguments are compelling. If someone else thinks > differently, they can say so, and explain their reasoning... > > The bottom line is that dbus has an MIT/X11-equivalent license, with > the addition of a *weaker* patent clause than LGPL/GPL already have. > The license was written by a lawyer and is perfectly sane. "Sane" and "written by a lawyer" are surely orthogonal to desirability from the point of view of free software. Havoc wrote in his blog: "I believe if you distributed D-Bus under GPL or LGPL, you would be making a patent grant of any patents affecting D-Bus. The AFL patent clause does not require you to make a patent grant; it still allows you to sue. You just have to stop distributing D-Bus while you do it. With the GPL or LGPL, you can never distribute in the first place, without giving up the right to sue at all. Unless I'm missing something, there's no way the AFL patent clause can be a problem unless LGPL or GPL would be a problem in the same context." IANAL, but... Hypothesis: Monster Corp distributes D-BUS under AFL, while believing that DB in fact violates patents held by Monster Corp. MC then sues users of DB. MC can no longer distribute DB under AFL, but they don't care! They have succeeded in causing trouble. But as Havoc says, if Monster Corp had distributed DB under *GPL they would have effectively made a patent grant and given up the right to sue, making this scenario impossible. OK, maybe there's no Monster Corp associated with D-BUS right now, but we know there _are_ such monsters around. This seems to me a _major_ reason to see *GPL as superior to AFL from the p.o.v. of free software. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 20 Apr 2009, Alexander Larsson wrote: > gvfs needs a session bus, not a system bus, so you're falling back to a > non-gvfs system. Thus no http support. OK, I suppose I can get this working on my own system, but my main point is: why does GTK include a function such as gtk_show_uri which depends on a big stack of unspecified stuff? At least this should be mentioned in the documentation. As I said before, up till very recently one has been able to rely on GTK functions "just working" so long as the compile-time dependencies are satisfied. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 2009-04-20 at 16:54 -0400, Allin Cottrell wrote: > On Mon, 20 Apr 2009, Alexander Larsson wrote: > > > 00, Allin Cottrell wrote: > > > On Mon, 20 Apr 2009, Alexander Larsson wrote: > > > > > > > On Mon, 2009-04-20 at 12:29 -0400, Allin Cottrell wrote: > > > > > On Mon, 20 Apr 2009, Alexander Larsson wrote: > > > > > > > > > > > On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: > > > > > > > As it's currently coded gtk_show_uri is bound > > > > > > > to fail if GVfs is not present. But more than that: it'll fail > > > > > > > even if GVfs _is_ present (as it is now on my system), if GVfs > > > > > > > does not in turn incorporate GConf support. I thought I'd read > > > > > > > that GConf was supposed to be deprecated, or on the way there? > > > > > > > > > > > > I don't understand what you propose? There is no in-use non-gconf > > > > > > setting for mapping default handlers for entire uri scheme. So, we > > > > > > lookup none which mean we then fall back to the per-mime default. > > > > > > > > > > The uri I'm testing with gtk_show_uri is a simple http reference. > > > > > So far as I can tell the attempt to handle it grinds to a halt in > > > > > g_file_query_info with iface->query_info = NULL. gnome_url_show > > > > > has no problem getting firefox to open it. > > > > > > > > Well, if you don't have gvfs installed then you will not be able to > > > > either look up the uri handler for the http uri scheme in gconf, nor > > > > will you be able to query_info for the mime type of the file on the http > > > > server. It should not grind to a halt though, can you explain in more > > > > detail what happens? > > > > > > I put some debugging statements into some of the gio files, and > > > here's what I'm getting when I try to open the http reference: > > > > > And an error message "Operation not supported". > > > > Thats not "grind to halt" really, but ok. What do you have built? > > It seems to load a libgvfsdbus.so, so gvfs seems to be there, but with > > no gconf module? Do you have a session dbus running? > > That's right; no gconf module in gvfs but dbus-daemon --system is > running. gvfs needs a session bus, not a system bus, so you're falling back to a non-gvfs system. Thus no http support. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 20 Apr 2009, Alexander Larsson wrote: > 00, Allin Cottrell wrote: > > On Mon, 20 Apr 2009, Alexander Larsson wrote: > > > > > On Mon, 2009-04-20 at 12:29 -0400, Allin Cottrell wrote: > > > > On Mon, 20 Apr 2009, Alexander Larsson wrote: > > > > > > > > > On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: > > > > > > As it's currently coded gtk_show_uri is bound > > > > > > to fail if GVfs is not present. But more than that: it'll fail > > > > > > even if GVfs _is_ present (as it is now on my system), if GVfs > > > > > > does not in turn incorporate GConf support. I thought I'd read > > > > > > that GConf was supposed to be deprecated, or on the way there? > > > > > > > > > > I don't understand what you propose? There is no in-use non-gconf > > > > > setting for mapping default handlers for entire uri scheme. So, we > > > > > lookup none which mean we then fall back to the per-mime default. > > > > > > > > The uri I'm testing with gtk_show_uri is a simple http reference. > > > > So far as I can tell the attempt to handle it grinds to a halt in > > > > g_file_query_info with iface->query_info = NULL. gnome_url_show > > > > has no problem getting firefox to open it. > > > > > > Well, if you don't have gvfs installed then you will not be able to > > > either look up the uri handler for the http uri scheme in gconf, nor > > > will you be able to query_info for the mime type of the file on the http > > > server. It should not grind to a halt though, can you explain in more > > > detail what happens? > > > > I put some debugging statements into some of the gio files, and > > here's what I'm getting when I try to open the http reference: > > > And an error message "Operation not supported". > > Thats not "grind to halt" really, but ok. What do you have built? > It seems to load a libgvfsdbus.so, so gvfs seems to be there, but with > no gconf module? Do you have a session dbus running? That's right; no gconf module in gvfs but dbus-daemon --system is running. > If you have gvfs installed but not with gconf what should happen is that > the query_info on the uri should sniff the mimetype and launch app > depending on that. > > Does gvfs stuff work at all in your installation? For instance, what > does "gvfs-info http://gretl.sourceforge.net"; print? It prints the same messages as I gave earlier, culminating in g_file_query_info: iface->query_info = NULL Error getting info: Operation not supported But, e.g., "gvfs-info /usr/local/bin/mplayer" works fine. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 2009-04-20 at 14:36 -0400, Allin Cottrell wrote: > On Mon, 20 Apr 2009, Alexander Larsson wrote: > > > On Mon, 2009-04-20 at 12:29 -0400, Allin Cottrell wrote: > > > On Mon, 20 Apr 2009, Alexander Larsson wrote: > > > > > > > On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: > > > > > As it's currently coded gtk_show_uri is bound > > > > > to fail if GVfs is not present. But more than that: it'll fail > > > > > even if GVfs _is_ present (as it is now on my system), if GVfs > > > > > does not in turn incorporate GConf support. I thought I'd read > > > > > that GConf was supposed to be deprecated, or on the way there? > > > > > > > > I don't understand what you propose? There is no in-use non-gconf > > > > setting for mapping default handlers for entire uri scheme. So, we > > > > lookup none which mean we then fall back to the per-mime default. > > > > > > The uri I'm testing with gtk_show_uri is a simple http reference. > > > So far as I can tell the attempt to handle it grinds to a halt in > > > g_file_query_info with iface->query_info = NULL. gnome_url_show > > > has no problem getting firefox to open it. > > > > Well, if you don't have gvfs installed then you will not be able to > > either look up the uri handler for the http uri scheme in gconf, nor > > will you be able to query_info for the mime type of the file on the http > > server. It should not grind to a halt though, can you explain in more > > detail what happens? > > I put some debugging statements into some of the gio files, and > here's what I'm getting when I try to open the http reference: > And an error message "Operation not supported". Thats not "grind to halt" really, but ok. What do you have built? It seems to load a libgvfsdbus.so, so gvfs seems to be there, but with no gconf module? Do you have a session dbus running? If you have gvfs installed but not with gconf what should happen is that the query_info on the uri should sniff the mimetype and launch app depending on that. Does gvfs stuff work at all in your installation? For instance, what does "gvfs-info http://gretl.sourceforge.net"; print? for me it does: gvfs-info http://gretl.sourceforge.net display name: / edit name: / type: unknown size: 14276 attributes: etag::value: "37c4-467d4ae02f640" standard::display-name: / standard::edit-name: / standard::content-type: text/html standard::size: 14276 id::filesystem: type=http,uri=http%3A%2F%2Fgretl.sourceforge.net,__mount_prefix=%2F time::modified: 1240063057 time::modified-usec: 0 which should lanuch whatever app is registered for text/html. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 20 Apr 2009, Alexander Larsson wrote: > On Mon, 2009-04-20 at 12:29 -0400, Allin Cottrell wrote: > > On Mon, 20 Apr 2009, Alexander Larsson wrote: > > > > > On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: > > > > As it's currently coded gtk_show_uri is bound > > > > to fail if GVfs is not present. But more than that: it'll fail > > > > even if GVfs _is_ present (as it is now on my system), if GVfs > > > > does not in turn incorporate GConf support. I thought I'd read > > > > that GConf was supposed to be deprecated, or on the way there? > > > > > > I don't understand what you propose? There is no in-use non-gconf > > > setting for mapping default handlers for entire uri scheme. So, we > > > lookup none which mean we then fall back to the per-mime default. > > > > The uri I'm testing with gtk_show_uri is a simple http reference. > > So far as I can tell the attempt to handle it grinds to a halt in > > g_file_query_info with iface->query_info = NULL. gnome_url_show > > has no problem getting firefox to open it. > > Well, if you don't have gvfs installed then you will not be able to > either look up the uri handler for the http uri scheme in gconf, nor > will you be able to query_info for the mime type of the file on the http > server. It should not grind to a halt though, can you explain in more > detail what happens? I put some debugging statements into some of the gio files, and here's what I'm getting when I try to open the http reference: g_io_module_load_module: loaded '/opt/gtk2/lib/gio/modules/libgvfsdbus.so' g_io_module_load_module: loaded '/opt/gtk2/lib/gio/modules/libgiofam.so' g_io_extension_point_lookup: 'gio-local-file-monitor' -> gio-local-file-monitor g_io_extension_point_lookup: 'gio-local-directory-monitor' -> gio-local-directory-monitor g_io_module_load_module: loaded '/opt/gtk2/lib/gio/modules/libgioremote-volume-monitor.so' g_io_extension_point_lookup: 'gio-local-directory-monitor' -> gio-local-directory-monitor g_io_extension_point_lookup: 'gio-local-file-monitor' -> gio-local-file-monitor g_io_extension_point_lookup: 'gio-native-volume-monitor' -> gio-native-volume-monitor g_io_extension_point_lookup: 'gio-vfs' -> gio-vfs g_io_extension_point_lookup: 'gio-vfs' -> gio-vfs g_io_extension_point_lookup: 'gio-desktop-app-info-lookup' -> gio-desktop-app-info-lookup g_io_extension_point_lookup: ep = 0x9e92e18 g_file_query_info: iface->query_info = NULL g_file_query_default_handler gave NULL for 'http://gretl.sourceforge.net' And an error message "Operation not supported". Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 2009-04-20 at 12:29 -0400, Allin Cottrell wrote: > On Mon, 20 Apr 2009, Alexander Larsson wrote: > > > On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: > > > As it's currently coded gtk_show_uri is bound > > > to fail if GVfs is not present. But more than that: it'll fail > > > even if GVfs _is_ present (as it is now on my system), if GVfs > > > does not in turn incorporate GConf support. I thought I'd read > > > that GConf was supposed to be deprecated, or on the way there? > > > > I don't understand what you propose? There is no in-use non-gconf > > setting for mapping default handlers for entire uri scheme. So, we > > lookup none which mean we then fall back to the per-mime default. > > The uri I'm testing with gtk_show_uri is a simple http reference. > So far as I can tell the attempt to handle it grinds to a halt in > g_file_query_info with iface->query_info = NULL. gnome_url_show > has no problem getting firefox to open it. Well, if you don't have gvfs installed then you will not be able to either look up the uri handler for the http uri scheme in gconf, nor will you be able to query_info for the mime type of the file on the http server. It should not grind to a halt though, can you explain in more detail what happens? For the gnome_url_show() case this calls the old gnome_vfs_url_show() which reads the http scheme default from gconf. This is the same behaviour as gtk_show_url would have if you had gvfs installed with gconf support. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 2009-04-20 at 12:45 -0400, David Zeuthen wrote: > That would give you a nice circular dependency if xdg-open(1) is ever > ported to use GIO [1] which is not at all unlikely... > > David > > [1] : under GNOME, xdg-open(1) uses gnome-open(1) which AFAICT uses > gnome-vfs2... gnome-open already uses GIO since 2.24 [1] so yes, we would have that loop already. OTOH, as libgnome depends on GConf, if you have gnome-open available, you're likely to also have GConf already installed. [1] http://svn.gnome.org/viewvc/libgnome/trunk/libgnome/gnome-open.c?view=markup Ciao, Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 2009-04-20 at 18:31 +0200, Christian Dywan wrote: > What about using "xdg-open" if GVfs is not available OR if gconf is > not available? That's a tiny script that can be easily installed > anywhere, even on less modern boxes. That would give you a nice circular dependency if xdg-open(1) is ever ported to use GIO [1] which is not at all unlikely... David [1] : under GNOME, xdg-open(1) uses gnome-open(1) which AFAICT uses gnome-vfs2... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Am Mon, 20 Apr 2009 17:00:41 +0200 schrieb Alexander Larsson : > On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: > > On Sun, 19 Apr 2009, David Zeuthen wrote: > > > > I could be wrong, but just briefly looking at the code it looks > > > like there is no default implementation of GDesktopAppInfoLookup > > > in GIO, there's only one in GVfs (that looks up stuff in GConf > > > under in /desktop/gnome/url-handlers/) so it's no > > > surprise things don't work if GVfs is not installed. > > > > Yes, that's right. As it's currently coded gtk_show_uri is bound > > to fail if GVfs is not present. But more than that: it'll fail > > even if GVfs _is_ present (as it is now on my system), if GVfs > > does not in turn incorporate GConf support. I thought I'd read > > that GConf was supposed to be deprecated, or on the way there? > > I don't understand what you propose? There is no in-use non-gconf > setting for mapping default handlers for entire uri scheme. So, we > lookup none which mean we then fall back to the per-mime default. > > Its entierly unreasonable to have a file:// uri handler, as that would > open *all* types of local files, overriding your per-mime specs. What about using "xdg-open" if GVfs is not available OR if gconf is not available? That's a tiny script that can be easily installed anywhere, even on less modern boxes. Just my 2 pfennig, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 20 Apr 2009, Alexander Larsson wrote: > On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: > > As it's currently coded gtk_show_uri is bound > > to fail if GVfs is not present. But more than that: it'll fail > > even if GVfs _is_ present (as it is now on my system), if GVfs > > does not in turn incorporate GConf support. I thought I'd read > > that GConf was supposed to be deprecated, or on the way there? > > I don't understand what you propose? There is no in-use non-gconf > setting for mapping default handlers for entire uri scheme. So, we > lookup none which mean we then fall back to the per-mime default. The uri I'm testing with gtk_show_uri is a simple http reference. So far as I can tell the attempt to handle it grinds to a halt in g_file_query_info with iface->query_info = NULL. gnome_url_show has no problem getting firefox to open it. -- Allin Cottrell Department of Economics Wake Forest University ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, 2009-04-20 at 10:43 -0400, Allin Cottrell wrote: > On Sun, 19 Apr 2009, David Zeuthen wrote: > > I could be wrong, but just briefly looking at the code it looks like > > there is no default implementation of GDesktopAppInfoLookup in GIO, > > there's only one in GVfs (that looks up stuff in GConf under > > in /desktop/gnome/url-handlers/) so it's no surprise things > > don't work if GVfs is not installed. > > Yes, that's right. As it's currently coded gtk_show_uri is bound > to fail if GVfs is not present. But more than that: it'll fail > even if GVfs _is_ present (as it is now on my system), if GVfs > does not in turn incorporate GConf support. I thought I'd read > that GConf was supposed to be deprecated, or on the way there? I don't understand what you propose? There is no in-use non-gconf setting for mapping default handlers for entire uri scheme. So, we lookup none which mean we then fall back to the per-mime default. Its entierly unreasonable to have a file:// uri handler, as that would open *all* types of local files, overriding your per-mime specs. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Sun, 19 Apr 2009, David Zeuthen wrote: > On Sun, 2009-04-19 at 20:05 -0400, Allin Cottrell wrote: > > I've recently been trying to purge my GTK app of "deprecated" > > stuff, and I tried replacing gnome_url_show() with > > gtk_show_uri(). No go; on invoking gtk_show_uri() I get > > "operation not supported". After some googling, it appears > > that one must have gvfs installed. OK, I download, build and > > install gvfs. But it doesn't help. Gvfs as built on my > > system (without configure or compilation errors) apparently > > can't handle URIs... > > > > This sort of thing is new, and IMO thoroughly obnoxious: up till > > now, one could depend on GTK functions working provided one had > > successfully installed the known stack of dependencies, which were > > checked at compile time for GTK and friends. Now we have GTK > > functions that may or may not work depending on unspecified > > dependencies... > > This is _supposed_ to work, there's already an unpleasant amount of work > in GIO to ensure that things work when things like GVfs (which requires > a modern flavor of Linux or UNIX) is not available. > > Now, GIO may not work as well as when GVfs installed (e.g. automounting > storage devices won't work unless the OS actively assists with playing > games like modifying /etc/fstab) but basics like launching a program for > URIs _should_ work - e.g. http, mailto, file:///path/to/some.jpg file or > other well-known URIs schemes. > > I could be wrong, but just briefly looking at the code it looks like > there is no default implementation of GDesktopAppInfoLookup in GIO, > there's only one in GVfs (that looks up stuff in GConf under > in /desktop/gnome/url-handlers/) so it's no surprise things > don't work if GVfs is not installed. Yes, that's right. As it's currently coded gtk_show_uri is bound to fail if GVfs is not present. But more than that: it'll fail even if GVfs _is_ present (as it is now on my system), if GVfs does not in turn incorporate GConf support. I thought I'd read that GConf was supposed to be deprecated, or on the way there? > I think it would be reasonable if GIO at least handled file:// > and maybe also http:// and mailto:// (the former by using the > MIME, the latter two by include a search path of well-known > applications like epiphany firefox, evolution and thunderbird) > and also the URI schemes used to launch Yelp. Agreed. > You should probably file a bug about this. OK, will do. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Sun, 2009-04-19 at 20:05 -0400, Allin Cottrell wrote: > On Sun, 19 Apr 2009, Havoc Pennington wrote: > > > On Sun, Apr 19, 2009 at 9:54 AM, Tim-Philipp Müller wrote: > > > You tell people not to worry. But many people clearly do seem to worry. > > > > Well, why don't these many people post a rational response to my > > points? I have not seen a rebuttal to > > http://mail.gnome.org/archives/gtk-devel-list/2009-April/msg8.html > > > > If it's a legitimate concern then someone specific will turn up > > and make a rational argument that's responsive to the points I > > made. > > Havoc may well be right with regard to libdbus, but IMO the burden > of proof rests the other way; that is, if code that is not under > *GPL is to be made part of glib, the onus is on those who would > make the addition to show without a particle of doubt that the > license is not an issue (i.e., "afaict" is not good enough). I think it is sufficient to observe that there already is an overwhelming amount of GPLv2+ and LGPLv2+ software already linking to libdbus-1 (including things like GVfs) and already shipped by major stakeholders... > On a matter that may or may not be related, I'm concerned about > possible "over-extension" of GTK/glib. I've recently been trying > to purge my GTK app of "deprecated" stuff, and I tried replacing > gnome_url_show() with gtk_show_uri(). No go; on invoking > gtk_show_uri() I get "operation not supported". After some > googling, it appears that one must have gvfs installed. OK, I > download, build and install gvfs. But it doesn't help. Gvfs as > built on my system (without configure or compilation errors) > apparently can't handle URIs; I suppose this facility must depend > on yet further third-party libraries. Avahi? It's all > undocumented, so I'm only guessing. > > This sort of thing is new, and IMO thoroughly obnoxious: up till > now, one could depend on GTK functions working provided one had > successfully installed the known stack of dependencies, which were > checked at compile time for GTK and friends. Now we have GTK > functions that may or may not work depending on unspecified > dependencies. Way NOT to go! This is _supposed_ to work, there's already an unpleasant amount of work in GIO to ensure that things work when things like GVfs (which requires a modern flavor of Linux or UNIX) is not available. Now, GIO may not work as well as when GVfs installed (e.g. automounting storage devices won't work unless the OS actively assists with playing games like modifying /etc/fstab) but basics like launching a program for URIs _should_ work - e.g. http, mailto, file:///path/to/some.jpg file or other well-known URIs schemes. I could be wrong, but just briefly looking at the code it looks like there is no default implementation of GDesktopAppInfoLookup in GIO, there's only one in GVfs (that looks up stuff in GConf under in /desktop/gnome/url-handlers/) so it's no surprise things don't work if GVfs is not installed. I think it would be reasonable if GIO at least handled file:// and maybe also http:// and mailto:// (the former by using the MIME, the latter two by include a search path of well-known applications like epiphany firefox, evolution and thunderbird) and also the URI schemes used to launch Yelp. You should probably file a bug about this. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Hi, On Sun, Apr 19, 2009 at 8:05 PM, Allin Cottrell wrote: > Havoc may well be right with regard to libdbus, but IMO the burden > of proof rests the other way; that is, if code that is not under > *GPL is to be made part of glib, the onus is on those who would > make the addition to show without a particle of doubt that the > license is not an issue (i.e., "afaict" is not good enough). I don't think "afaict" is a good summary of the detailed analysis of the problem I also posted. "afaict" was just allowing for the fact that someone could show up and have some counterargument, in an "anything is possible" kind of sense. Let's not have this "well just the fact that a question was raised is a problem" claim. There's a problem if there's an actual problem. Logic can be applied to the situation, the licenses can be read, probabilities analyzed, and it's quite possible to reach a rational conclusion. I think my arguments are compelling. If someone else thinks differently, they can say so, and explain their reasoning. And let's not mix this licensing stuff in with technical arguments. Some people are concerned about glib dependencies, others would rather use a different dbus implementation than libdbus for technical reasons, etc.; those are all fine discussions, but not related. The bottom line is that dbus has an MIT/X11-equivalent license, with the addition of a *weaker* patent clause than LGPL/GPL already have. The license was written by a lawyer and is perfectly sane. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Sun, 19 Apr 2009, Havoc Pennington wrote: > On Sun, Apr 19, 2009 at 9:54 AM, Tim-Philipp Müller wrote: > > You tell people not to worry. But many people clearly do seem to worry. > > Well, why don't these many people post a rational response to my > points? I have not seen a rebuttal to > http://mail.gnome.org/archives/gtk-devel-list/2009-April/msg8.html > > If it's a legitimate concern then someone specific will turn up > and make a rational argument that's responsive to the points I > made. Havoc may well be right with regard to libdbus, but IMO the burden of proof rests the other way; that is, if code that is not under *GPL is to be made part of glib, the onus is on those who would make the addition to show without a particle of doubt that the license is not an issue (i.e., "afaict" is not good enough). On a matter that may or may not be related, I'm concerned about possible "over-extension" of GTK/glib. I've recently been trying to purge my GTK app of "deprecated" stuff, and I tried replacing gnome_url_show() with gtk_show_uri(). No go; on invoking gtk_show_uri() I get "operation not supported". After some googling, it appears that one must have gvfs installed. OK, I download, build and install gvfs. But it doesn't help. Gvfs as built on my system (without configure or compilation errors) apparently can't handle URIs; I suppose this facility must depend on yet further third-party libraries. Avahi? It's all undocumented, so I'm only guessing. This sort of thing is new, and IMO thoroughly obnoxious: up till now, one could depend on GTK functions working provided one had successfully installed the known stack of dependencies, which were checked at compile time for GTK and friends. Now we have GTK functions that may or may not work depending on unspecified dependencies. Way NOT to go! Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Hi, On Sun, Apr 19, 2009 at 9:54 AM, Tim-Philipp Müller wrote: > You tell people not to worry. But many people clearly do seem to worry. Well, why don't these many people post a rational response to my points? I have not seen a rebuttal to http://mail.gnome.org/archives/gtk-devel-list/2009-April/msg8.html If it's a legitimate concern then someone specific will turn up and make a rational argument that's responsive to the points I made. As far as I'm concerned, libdbus's license situation is the same as that of glib itself, because it's effectively the same as LGPL. And guess what - the same bankrupt company that contributed to libdbus contributed to glib and gtk, too. Plus hundreds of other people. libdbus at least has relicense permission for every bit of code except the codefactory bits. If someone wants to do something productive, it would be great to add to dbus/COPYING a note that all new code, and almost all existing code, is MIT/X11. So if we do solve the codefactory code through rewriting some files, the rest is all already relicensed. Otherwise it isn't clear what license new patches are going in under. My only question here is whether there were any missing relicense responses other than the codefactory one. > It seems to me that by making GLib, the cornerstone of our platform, > depend on libdbus, we'd be creating a fair bit of uncertainty Only because people have a whisper campaign about how there's some unclear problem, when they (afaict) are just wrong. I don't see a reason we should care about how "some people" have some unspecified, unexplained (and as best I can figure, flat wrong) worries; and these "some people" are not turning up. If someone shows up and actually makes a convincing argument, that's different. Even if there's a problem, which one sounds easier: * replace the parts of libdbus that CodeFactory wrote (which are really not that large.) * reimplement the entirety of libdbus and dbus-daemon and port everything using them I would advocate lazy-replacing the codefactory code at the point that it is clearly a practical issue. Which will be never. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Thu, 2009-04-02 at 20:34 -0400, Havoc Pennington wrote: > > - What of the license issues? > > GLib is LGPL. libdbus-1 is not. (...) > > Just for the record, my comment on this has always been that the > license issues were not earth-shattering to begin with, and the > relicensing was just throwing a bone to people who cared. (...) > > (snip commentary and what-ifs) > > There are many things to worry about in life, but this is not one of them. I hear what you're saying, and I don't really have a strong opinion or much detailed knowledge on the licensing subject myself, but I can't help but feel that there's still something wrong about all this. You tell people not to worry. But many people clearly do seem to worry. It seems to me that by making GLib, the cornerstone of our platform, depend on libdbus, we'd be creating a fair bit of uncertainty, and I can't see that as being good for the platform. At best this means inconvenience and hassle for people already building on our platform while they evaluate the new situation for themselves. At worst it deters people from considering or adopting it. I don't think this is something we'd even be considering if there was a good alternative. Just to be clear, I'm very much in favour of adding DBus support to GLib, I'm just a bit reluctant about shrugging off the dbus license aspect like that. Cheers -Tim ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Gustavo Noronha wrote: On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote: - What do we do about the added 16bit integer types that are supported by the DBus protocol, but don't have corresponding fundamental types in GObject ? EggDbus currently has fundamental types for them. It just stroke me. What about int32? Should it be added for completeness sake, or it is a non-issue? On every platform on which glib currently runs "int" is exactly 32 bits in size. Maybe we get in trouble in some distant future time when we decide to port to some exotic new platform, but for now it's not a problem. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Hi, On Fri, Apr 3, 2009 at 2:56 PM, Will Thompson wrote: > I don't think that relying on having correct introspection data to > marshall messages is a sound idea for a DBus binding. There's no way you can marshal a message without the introspection data. It can be implicit (i.e. you happen to pass an int, or an array of foo, so the marshaler marshals an int or an array of foo); or it can be explicit (someone specifies the signature somewhere); but either way, the two sides of an IPC connection have to agree in advance at code-writing time what the signature of something is. (Modulo overloading/variants, i.e. an agreement to do switching on type at runtime, of course.) The JavaScript/gjs dbus bindings work very well, and there's no dbus signature stuck to a JS integer type to say what kind of integer it is. The way it works is that you provide the interface and the types get coerced. So if an interface takes an int8, you can pass in an integer or a double or a bool or anything that can convert to int8, and it gets converted. The need for sticking all this extra goo in GType for dbus-glib's benefit is arising because dbus-glib is broken. If all the design decisions are correct, said goo should not be needed. Which is good, because the goo is completely unnatural in C, not to mention bloated. When was the last time you made a GHashTable full of GValue and you were *not* using dbus-glib? The answer for me is I've been writing "G" C for a decade and have never done this. A decent C binding isn't going to "leak" freaky data types and data structures into the rest of your program. The only place this type info should need to be in a *value* (rather than an interface description) is for variants. That's where GVariant comes in. > But for this to be useful, the binding has to support > complex types just as much, if not more, than simple ones, particularly > in a language like C. The *binding* needs to support complex types, but the *language* doesn't. In effect, libgobject defines a dialect or superset-language of C. If it were true that GType and libgobject had to exactly support all the types dbus does, it would also be true that to map dbus to python or JavaScript, those languages would have to support exactly all the types dbus does. But that isn't true. The problem arises when you try to specify dbus signatures using the type system of the *language* instead of the type system of *dbus*. This is simply a bad idea. The introspection data - wherever it lives, implicit or explicit - should be in dbus's signature format, or something semantically equivalent. It doesn't make sense to express a dbus signature (or more generally, the signature of a serialized data blob) in GTypes, imo. Just makes a mess. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Fri, 2009-04-03 at 19:56 +0100, Will Thompson wrote:
> I don't think that relying on having correct introspection data to
> marshall messages is a sound idea for a DBus binding. The C
> representation of an 'a{uas}' where the values are all the empty list
> should contain all the information you need to determine its D-Bus type.
> It sounds like with EggDBus that's not possible without you discovering
> the type by external means. If the C-side type system isn't powerful
> enough to express the D-Bus-side types (which GType isn't), then the
> C-side type system should be improved. Gluing the D-Bus type onto the
> side doesn't sound like a clean way to do this to me.
Keep in mind that the goal of EggDBus was just to provide an object
mapping using generated code. With generated code it is a non-issue
whether you have to pass just a GType or the pair (GType, D-Bus
signature) since all that happens from generated code.
Of course this approach is not very clean if your goal is to also
provide some a C API that is useful outside the context of generated
code. While I don't think that's compelling (you are going to lose type
safety for starters) apparently a lot of people want this kind of API. I
agree it's sensible to have.
> Apparently, back when Telepathy was started, dbus-glib used to have a
> similar problem with collections containing structs. It relied on
> inspecting the contents of a GValueArray to determine the type of the
> struct it represents, which obviously can't work for a(ss) since the
> array might be empty. (Rob Taylor fixed this by adding a parameterized
> struct type.) More recently, Rob McQueen had to fix dbus-glib to allow
> complex types in maps. If the binding gets the type system right and
> complete from the start, problems like this (and the current situation
> where dbus-glib can't send 16-bit ints, causing interoperability
> problems with bindings which expect them) won't arise later.
Yes, we probably want a type system where you can do e.g.
g_bus_send_message (connection,
"org.foo.SomeService",
"/org/foo/SomeObject",
"org.foo.SomeInterface.SomeMethod",
cancellable,
async_ready_callback,
G_TYPE_PTR_ARRAY (G_TYPE_PTR_ARRAY (G_TYPE_STRING)),
array_of_array_of_strings,
G_TYPE_HASH_TABLE (G_TYPE_STRING,
G_TYPE_PTR_ARRAY (G_TYPE_STRING)),
hash_of_strings_to_ptr_array_of_strings,
G_TYPE_INVALID);
instead of
g_bus_send_message (connection,
"org.foo.SomeService",
"/org/foo/SomeObject",
"org.foo.SomeInterface.SomeMethod",
cancellable,
async_ready_callback,
G_TYPE_PTR_ARRAY, "aas",
array_of_array_of_strings,
G_TYPE_HASH_TABLE, "a{sas}",
hash_of_strings_to_ptr_array_of_strings,
G_TYPE_INVALID);
e.g. enable the API user to express a complete D-Bus signature via GType
instead of having to pass both the GType and the D-Bus signature. That
is essentially what you are talking about right?
Personally I don't think it's a big deal having to do the latter. In my
view both of these approaches are much worse than having a generated
GInterface for the org.foo.SomeInterface D-Bus interface and having
GObject-derived classes for the structs you need. YMMV though.
> > The point is that you can always get to the D-Bus signature and from
> > that you can infer the complete type.
>
> dbus-python has shown that that's not true. When marshalling a dict (for
> instance), it has to guess what the type is, and it sometimes guesses
> wrongly, leading to hard-to-debug problems. It tries to quietly
> introspect behind your back to work around this, and that too causes
> problems.
Certainly if you pass your low-level code the D-Bus signature for a
single complete type (like the above example and like EggDBus does) no
guessing is _ever_ needed. I mean, the D-Bus signature _defines_ exactly
what to output so if you run into problems (e.g. with Python) maybe it's
because you have a problem decoding the native types the user passed in
(which sounds easy to run into with Python).
> > The set of distinct D-Bus signatures you encounter in a app where you
> > would need to do this (e.g. no need to do this for primitive types) is
> > most likely bounded to a couple of dozen types at the most (unless you
> > are some odd-ball corner case like a D-Bus version of gconf-editor) so I
> > don't think this is a big deal at all.
>
> I think regarding types more complicated than 'as', 'b', 'i' etc. as
> "odd-ball corner cases" is a mistake,
I think you misunderstood what I meant with odd-ball cases here. What I
meant was with a D-Bus-ified version gconf-editor being an oddball case
was s
Re: GLib plans for the next cycle
David Zeuthen wrote:
> On Thu, 2009-04-02 at 19:05 -0400, Ryan Lortie wrote:
>> Even if we have support for querying the element type of an array, for
>> example, we can get into situations where we can still have type errors.
>> Consider the case of an array of arrays of strings (which is a fairly
>> simple DBus type: "aas").
>>
>> In this case, if you have a GArray, and query its type you will see the
>> answer is "G_TYPE_ARRAY". This doesn't help you very much. You have to
>> grab one of the inside arrays and query its type. If the top array
>> happens to be the empty array then you're really in trouble because now
>> you have no way of determining the (complete) type of this empty array.
>
> If you are not using a D-Bus variant this information is explicitly
> available as part of the interface contract and it is also in the the
> introspection data
>
> http://people.freedesktop.org/~david/eggdbus-HEAD/eggdbus-eggdbusinterface.html#EggDBusInterfaceInfo
>
> as a D-Bus signature.
I don't think that relying on having correct introspection data to
marshall messages is a sound idea for a DBus binding. The C
representation of an 'a{uas}' where the values are all the empty list
should contain all the information you need to determine its D-Bus type.
It sounds like with EggDBus that's not possible without you discovering
the type by external means. If the C-side type system isn't powerful
enough to express the D-Bus-side types (which GType isn't), then the
C-side type system should be improved. Gluing the D-Bus type onto the
side doesn't sound like a clean way to do this to me.
Apparently, back when Telepathy was started, dbus-glib used to have a
similar problem with collections containing structs. It relied on
inspecting the contents of a GValueArray to determine the type of the
struct it represents, which obviously can't work for a(ss) since the
array might be empty. (Rob Taylor fixed this by adding a parameterized
struct type.) More recently, Rob McQueen had to fix dbus-glib to allow
complex types in maps. If the binding gets the type system right and
complete from the start, problems like this (and the current situation
where dbus-glib can't send 16-bit ints, causing interoperability
problems with bindings which expect them) won't arise later.
Talking about switching EggDBus to use GBus or GVariant in the future
seems like a non-starter; it would inevitably involve breaking the API.
So before putting a D-Bus binding into GLib, we should make sure it's
good enough to represent D-Bus cleanly, without needing the library user
to jump through hoops to make it work.
> The point is that you can always get to the D-Bus signature and from
> that you can infer the complete type.
dbus-python has shown that that's not true. When marshalling a dict (for
instance), it has to guess what the type is, and it sometimes guesses
wrongly, leading to hard-to-debug problems. It tries to quietly
introspect behind your back to work around this, and that too causes
problems.
> The set of distinct D-Bus signatures you encounter in a app where you
> would need to do this (e.g. no need to do this for primitive types) is
> most likely bounded to a couple of dozen types at the most (unless you
> are some odd-ball corner case like a D-Bus version of gconf-editor) so I
> don't think this is a big deal at all.
I think regarding types more complicated than 'as', 'b', 'i' etc. as
"odd-ball corner cases" is a mistake, particularly when talking about
one of the core components of the GNOME platform. The fact that D-Bus
has an expressive recursive type system is good, since it means you can
model interesting concepts without forcing them into an incorrect
representation. But for this to be useful, the binding has to support
complex types just as much, if not more, than simple ones, particularly
in a language like C.
Telepathy uses some pretty complex D-Bus types; an example that comes to
mind is 'a{ua(a{sv}as)}'. If working with this type in the standard GLib
D-Bus binding is no less painful than it currently is with dbus-glib,
then using a component of the GNOME stack with a standard GNOME binding
will be unnecessarily difficult. I really don't want to end up in a
situation where I have to use an external library instead of the one
inside GLib to make working with Telepathy less painful.
Regards,
--
Will
signature.asc
Description: OpenPGP digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote: > - What do we do about the added 16bit integer types that are supported > by the DBus protocol, but don't have corresponding fundamental types in > GObject ? EggDbus currently has fundamental types for them. It just stroke me. What about int32? Should it be added for completeness sake, or it is a non-issue? -- Gustavo Noronha GNOME contributor ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Thu, 2009-04-02 at 19:05 -0400, Ryan Lortie wrote: > - Do we want glib depending on libdbus? >It is my understanding that the intention is that glib is at the >bottom of the stack. I felt like the reason that the GIO/gvfs split >occured the way it did was in a large part because the gvfs client >would not be able to use libdbus if it was in glib. This is not really a correct description. The vfs part of GIO is a way to access whatever kind of filesystem you have availible on your operating system/desktop. Whereas gvfs is an implementation of virtual filesystem mounts specifically designed for modern unix desktops. It doesn't really make sense to have gvfs in glib, as its not what would be used on all platforms. For instance, its not used on win32, and its not used when using glib on a non-desktop unix desktop (without a session, dbus, etc). One could of course put only the clients side of gvfs inside glib, similar to the way we have the client side of some win32 http vfs stuff in glib. However, this would mean we had to immediately freeze the cross-process protocols and update them in lock-step which would be a gigantic pain in the ass. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Thu, 2009-04-02 at 19:05 -0400, Ryan Lortie wrote: > Hi > > Matthias Clasen wrote: > > One thing that has been tossed around for a long time is that it would > > be really good to have DBus support on the Glib level. > > Agree strongly, but I'm not sure of the timing. A couple of people have > raised a few questions with me recently (in light of the noise I've been > making about GVariant and GBus) about how this could be happening yet. > > A few of the concerns that were raised: > > - How will compatibility between EggDBus and GBus be? >I think this is not a very big concern, actually. These two things >are currently aimed in very different directions. GBus is very >low-level at the moment, mostly only implementing things that EggDBus >currently uses libdbus-1 to do. Right, the point of the EggDBus effort is really just to provide a reasonable object mapping for C programmers using GObject, e.g. the focus is really the C object binding. Yes, this involves code generation (and way too much code at the moment but that is fixable) since we care about things like type safety and other crap. Anyway, so Havoc made a good point that we should also making things easy for non-C language bindings on top of GLib so he wrote a big laundry list of things that I largely agree with (that won't affect the C object binding that EggDBus gives you) and I'm planning to implement. Presumably if EggDBus is using GBus instead of libdbus-1 this would have to come from GBus ;-) Some relevant threads http://mail.gnome.org/archives/gtk-devel-list/2009-February/msg00121.html http://mail.gnome.org/archives/gtk-devel-list/2009-February/msg00123.html http://mail.gnome.org/archives/gtk-devel-list/2009-March/msg00026.html http://mail.gnome.org/archives/gtk-devel-list/2009-March/msg00030.html So, yeah, from a 50,000 feet perspective you are right that it's not important for the EggDBus C object binding whether libdbus-1 or gbus or whatever is used. The important point, however, is that the non C object binding stuff is reasonably efficient so it's usable by non-C object mappings without having to copy a lot of values around and allocate memory to free it again nano-seconds later. License issues aside, I'm not exactly sure why we'd want to avoid using libdbus-1. My view has always been that application programmers should not even have to know that libdbus exist because they should be using a language specific object mapping that hides libdbus-1... using either generated code or varargs-ish functions depending on your taste and the size and complexity of the D-Bus service you are providing and/or using. > > - What do we do about collections ? EggDbus adds typesafe GObject > > wrappers around GHashTable and GArray. Other people have grandiose plans > > to force java/.net style collection interfaces into GObject. > > > >My proposal: Dodge the issue by just adding the minimal necessities > > to GObject: a type for GArray (GHashTable already has one), and an api > > to associate element type information to arrays and hash tables. > > I suspect that this will be insufficient. In general, the GType system > isn't powerful enough to express DBus types properly. This is what lead > to the creation of GVariant. > > Even if we have support for querying the element type of an array, for > example, we can get into situations where we can still have type errors. > Consider the case of an array of arrays of strings (which is a fairly > simple DBus type: "aas"). > > In this case, if you have a GArray, and query its type you will see the > answer is "G_TYPE_ARRAY". This doesn't help you very much. You have to > grab one of the inside arrays and query its type. If the top array > happens to be the empty array then you're really in trouble because now > you have no way of determining the (complete) type of this empty array. If you are not using a D-Bus variant this information is explicitly available as part of the interface contract and it is also in the the introspection data http://people.freedesktop.org/~david/eggdbus-HEAD/eggdbus-eggdbusinterface.html#EggDBusInterfaceInfo as a D-Bus signature. For d-feet D-Bus debugging / introspection style apps you can also get a EggDBusInterfaceInfo struct by introspecting objects at run-time (again as a D-Bus signature) using egg_dbus_object_proxy_introspect(). If you are using a D-Bus variant the signature is available on EggDBusVariant. The point is that you can always get to the D-Bus signature and from that you can infer the complete type. So, you are right that the G type system _alone_ isn't powerful enough if we do it this way. E.g. you will need to augment the type with the D-Bus signature and then you have all the information you need. I'm not sure that's a big deal. (Note that in for most real-life apps this is not a big deal. People normally code their applications against a known interface contract (e.g. they know the D-Bus API at coding
Re: GLib plans for the next cycle
Hi, On Thu, Apr 2, 2009 at 7:05 PM, Ryan Lortie wrote: > - How does it fit with gobject-introspection? > - Do we need code generation? I'm on the same page with you here, but I think the fix is to split the object mapping from the other pieces (as outlined in my long manifesto previously). Then go ahead and get the other pieces stable and usable, and give the various object mapping ideas and codebases some more time to settle. > - What of the license issues? > GLib is LGPL. libdbus-1 is not. The recent attempt to relicense > libdbus-1 failed spectacularly due to copyright in a large chunk of it > having been acquired by a bank (or something?) when CodeFactory AB > folded. Just for the record, my comment on this has always been that the license issues were not earth-shattering to begin with, and the relicensing was just throwing a bone to people who cared. Not sure "large chunk" is super accurate, either. As a practical matter this topic is highly overblown. Nobody has yet explained (to my satisfaction anyway) how the libdbus license has an issue the LGPL does not have. Perhaps we should get Luis or SFLC on the case, but I'm not sure it's worth their time. http://log.ometer.com/2007-07.html#17.2 3 points here. 1. AFL+GPL is the same as LGPL+GPL in the case people are complaining about. LGPL is a dual-license - the part that's the LGPL itself, OR you can choose GPL. The part that's the LGPL itself is not GPL-compatible - it's a totally different license. That's why it gives you the choice of GPL instead. libdbus is the same way, but it's choice of AFL (much less restrictive than LGPL) or GPL. Remember, when you link a GPL program to an LGPL library you are using the library under GPL. Same if you link a GPL program to dbus. The difference between dbus and an LGPL library arises only if your program is *not* GPL. You have to choose whether you want LGPL or GPL when using GTK, and AFL or GPL when using libdbus. You can't say your program is using both choices. You have to choose. If a program is GPL+Exception, I don't think you can choose GPL for an LGPL library. You have to use the LGPL terms. This means, however, that your program must, in its exception, allow linking to the LGPL library. It could also allow linking to an AFL library, if so. If your exception doesn't allow this, then your program's GPL terms require that the library be distributed under GPL... but if the library is GPL, you can't have the exception. So GPL+exception is not compatible with an LGPL library unless the exception includes LGPL libraries. 2. It's unclear that the AFL2.1 is GPL-incompatible. GPLv2 is hard to understand on this topic, so it's hard to know. GPLv3 may be clearer. But as generally understood, if you distributed libdbus under either GPL version, you'd be licensing your patents under GPL. All AFL2.1 requires is that if you sue *with respect to libdbus* claiming libdbus infringes your patents, you can't distribute libdbus. But distributing libdbus under GPL requires you not to sue with respect to libdbus. So in practice, there is no situation AFL adds further restrictions over GPL. The GPL already prevents you from suing for infringement claiming that libdbus infringes your patents, *while distributing libdbus yourself*, because distributing libdbus yourself necessarily licenses your patents. There is no way, under either GPL or AFL, to distribute libdbus while simultaneously suing users of libdbus saying libdbus infringes your patents. The licenses agree on this. As does LGPL for that matter. So the situation where 1) AFL keeps you from doing something and 2) GPL allowed you to do that same thing, does not ever exist. As a result, I don't think there's a "further restriction." To me "further restriction" means "prevents something the GPL allowed me to do" and the AFL does not do so. AFL is pretty much an MIT/X11 license and an extremely liberal and toothless patent clause (compared to the GPL's patent requirements). 3. There's no practical issue, even if there's a theoretical one (which I don't think there is) _Even_ if I'm wrong on the theory (IANAL), the case where it even _matters_ is that some non-software company who owns the assets of a small business (codefactory) that went bankrupt years ago, somehow opens a musty old file, cross-references it with open source forums on the Internet, realizes they could disrupt the distribution of something called "Rhythmbox," goes to lots of legal time and expense to do so... and then we either rewrite the Anders-written code in libdbus, or add an exception to the GPL in Rhythmbox, or relicense Rhythmbox to GPLv3, or some other solution, and we solve the problem. There are many things to worry about in life, but this is not one of them. btw, I believe we were going to add a notice to COPYING in libdbus to the effect of "all new code is also MIT/X11, and most code is MIT/X11, but a few bits are GPL/AFL" so that new contributions are MIT/X11 and we do
Re: GLib plans for the next cycle
Hi Matthias Clasen wrote: One thing that has been tossed around for a long time is that it would be really good to have DBus support on the Glib level. Agree strongly, but I'm not sure of the timing. A couple of people have raised a few questions with me recently (in light of the noise I've been making about GVariant and GBus) about how this could be happening yet. A few of the concerns that were raised: - How will compatibility between EggDBus and GBus be? I think this is not a very big concern, actually. These two things are currently aimed in very different directions. GBus is very low-level at the moment, mostly only implementing things that EggDBus currently uses libdbus-1 to do. - Why is there EggDBusVariant instead of GVariant? How will these map? See below. - Do we want glib depending on libdbus? It is my understanding that the intention is that glib is at the bottom of the stack. I felt like the reason that the GIO/gvfs split occured the way it did was in a large part because the gvfs client would not be able to use libdbus if it was in glib. - What of the license issues? GLib is LGPL. libdbus-1 is not. The recent attempt to relicense libdbus-1 failed spectacularly due to copyright in a large chunk of it having been acquired by a bank (or something?) when CodeFactory AB folded. - How does it fit with gobject-introspection? It seems like there could be a lot of advantage here in terms of easily exporting objects on the service side without need for large tables, if/elseif/elseif statements or code generation. - Do we need code generation? Somewhat related to the last question, clearly: maybe we can avoid having generated code. There is precedent for generated code in glib, certainly (enums, marshalers, etc.) but adding more is still a significant decision -- particularly when alternatives are available. This is a huge ideological debate, of course: I'm not going to suggest that this approach is wrong, but I guess my preference would lie on the other side, and it seems like this isn't something that has really been flamed on as much as maybe it should be. Havoc tried to bring this topic up in another thread and as far as I can tell it didn't get a whole lot of play there. There is also some work by Ryan Lortie on a Glib-compatible Dbus api called gbus. It is lower-level than EggDbus, and might be suitable as a replacement for libdbus. While I have no clear idea yet how EggDbus and gbus will eventually relate, it is worth pointing out that EggDbus' use of libdbus is an implementation detail that is not exposed in the api, so it would be possible to replace it by something like gbus later on. GBus is in a completely different problem space than EggDBus, so there's not much toe-stepping going on here. I'm not certain GBus is stable enough that I'd feel comfortable encouraging its uptake during this cycle. In the meantime, that means that we'd have to deal with the license and external dependency problems that come with using libdbus-1. It also means that we might be in trouble later if we find out that the abstraction was a tiny bit leaky. I do intend to propose GVariant for glib this cycle -- I'm going to be creating a branch of the newly-converted glib git repository and merging GVariant into it soon. Assuming all goes well, EggDBus could be using it at this point. This would make future transition to GBus extremely easy and would avoid converting between two different value types that do essentially the same thing. Once we release EggDBus with one variant type or the other appearing on the public API, we're more or less stuck that way forever. - What do we do about collections ? EggDbus adds typesafe GObject wrappers around GHashTable and GArray. Other people have grandiose plans to force java/.net style collection interfaces into GObject. My proposal: Dodge the issue by just adding the minimal necessities to GObject: a type for GArray (GHashTable already has one), and an api to associate element type information to arrays and hash tables. I suspect that this will be insufficient. In general, the GType system isn't powerful enough to express DBus types properly. This is what lead to the creation of GVariant. Even if we have support for querying the element type of an array, for example, we can get into situations where we can still have type errors. Consider the case of an array of arrays of strings (which is a fairly simple DBus type: "aas"). In this case, if you have a GArray, and query its type you will see the answer is "G_TYPE_ARRAY". This doesn't help you very much. You have to grab one of the inside arrays and query its type. If the top array happens to be the empty array then you're really in trouble because now you have no way of determining the (complete) type of this empty array. It's also not reasonable to (dynamically?) create a new GType for the exact typ
Re: GLib plans for the next cycle
2009/3/3 Havoc Pennington > Hi, > > On Tue, Mar 3, 2009 at 6:03 AM, Mikkel Kamstrup Erlandsen > wrote: > > 2009/3/2 Havoc Pennington > >> > >> Anyway, I think there is no difference between method calls and > >> message passing. The only difference is in whether the client side API > >> is made to look just like a native object. But that's totally > >> orthogonal to the IDL and to the wire protocol. > > > > To quote yourself: "This is perhaps a misunderstanding". Or at least a > > provocative statement :-) > > > > For instance Steve Vinoski (one of the RPC/distributed systems grand old > > men) has a lot of blog posts devoted to the subject of RPC vs message > > passing. A good starting point is PDF paper linked here: > > http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/ > > > > I think you can put an RPC style API on top of an IDL based on message > > passing, but putting a message passing API on top of an RPC style IDL > might > > not be a good idea (depending on the IDL in question of course as well as > > the nature of the actual remote transport mechanism). > > > > I agree with what Vinoski says there, but he's pretty much talking > about the API, not what's on the wire. > > There's only so much you can put on the wire; i.e. some kind of > messages ... given that it's a TCP socket, all you can change really > is what format they're in. I can send a dbus message and get back a > dbus reply message, or send an http request and get back http reply. > I'm sending some parameters to the remote, it does something, it sends > back any results. > > Anyway dbus has messages on the wire but I think that's quite happy to > be mapped to an rpc-looking (method call) sort of API, or not, as > people see fit. Personally my favorite mapping is in JavaScript and > looks like a method call except the method takes a callback arg which > receives the return values, rather than ever returning anything > immediately. Just as people might often do http. > > No doubt this is just terminology confusion. The point is, you can > make dbus look like rpc or not. There's nothing in the protocol to > stop you going either way. Right. Reading through the posts (and linked articles) in all the spin-off threads I think we all agree more or less. It is mostly a matter on how one puts it. Here's to a brighter future of sweet message passing! :-) -- Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Hi, On Tue, Mar 3, 2009 at 6:03 AM, Mikkel Kamstrup Erlandsen wrote: > 2009/3/2 Havoc Pennington >> >> Anyway, I think there is no difference between method calls and >> message passing. The only difference is in whether the client side API >> is made to look just like a native object. But that's totally >> orthogonal to the IDL and to the wire protocol. > > To quote yourself: "This is perhaps a misunderstanding". Or at least a > provocative statement :-) > > For instance Steve Vinoski (one of the RPC/distributed systems grand old > men) has a lot of blog posts devoted to the subject of RPC vs message > passing. A good starting point is PDF paper linked here: > http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/ > > I think you can put an RPC style API on top of an IDL based on message > passing, but putting a message passing API on top of an RPC style IDL might > not be a good idea (depending on the IDL in question of course as well as > the nature of the actual remote transport mechanism). > I agree with what Vinoski says there, but he's pretty much talking about the API, not what's on the wire. There's only so much you can put on the wire; i.e. some kind of messages ... given that it's a TCP socket, all you can change really is what format they're in. I can send a dbus message and get back a dbus reply message, or send an http request and get back http reply. I'm sending some parameters to the remote, it does something, it sends back any results. Anyway dbus has messages on the wire but I think that's quite happy to be mapped to an rpc-looking (method call) sort of API, or not, as people see fit. Personally my favorite mapping is in JavaScript and looks like a method call except the method takes a callback arg which receives the return values, rather than ever returning anything immediately. Just as people might often do http. No doubt this is just terminology confusion. The point is, you can make dbus look like rpc or not. There's nothing in the protocol to stop you going either way. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: DBus IDL (Was Re: GLib plans for the next cycle)
Hi Brian, >> I understand that there is no difference on-the-wire between a >> function-call and message passing. The difference is in peoples >> perceptions and expectations. >> >> When I read CORBA IDL and see: >> >> int AFunction (int, int); >> >> Because of the connotations provided to me by years of procedural >> languages I expect this function call to be synchronous. I hope to break >> these perceptions by providing a message-based IDL. > > I don't have this perception; I think you're mistaking your own > perceptions for the majority's. > > One of the huge benefits of this entire exercise is to "hide" dbus calls > and make them look like methods on an object. If you're going to avoid > calling dbus methods "methods," then I fail to see the point. > > Whether or not the object is local (in-process) or not is irrelevant. > Whether or not the method call is sync or async is also irrelevant. It's > a method call, pure and simple. DBus itself even calls them method > calls. All you're doing by avoiding that in the IDL is making us learn > and remember yet another confusing and incompatible syntax. > > I ask you to *please* reconsider not using some normal method-call > syntax for the IDL. There's really no reason to do otherwise. If there > really is a perception problem, people need to fix that on their own. > I am actually re-using something that already exists. The struct-like syntax for message-passing interfaces is almost exactly the same as google protocol buffers language. http://code.google.com/apis/protocolbuffers/docs/proto.html#simple Thanks Mark ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
2009/3/2 Havoc Pennington > Anyway, I think there is no difference between method calls and > message passing. The only difference is in whether the client side API > is made to look just like a native object. But that's totally > orthogonal to the IDL and to the wire protocol. > To quote yourself: "This is perhaps a misunderstanding". Or at least a provocative statement :-) For instance Steve Vinoski (one of the RPC/distributed systems grand old men) has a lot of blog posts devoted to the subject of RPC vs message passing. A good starting point is PDF paper linked here: http://steve.vinoski.net/blog/2008/07/01/convenience-over-correctness/ I think you can put an RPC style API on top of an IDL based on message passing, but putting a message passing API on top of an RPC style IDL might not be a good idea (depending on the IDL in question of course as well as the nature of the actual remote transport mechanism). -- Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: DBus IDL (Was Re: GLib plans for the next cycle)
On Tue, 03 Mar 2009 10:55:33 +0100 Alexander Larsson wrote: > On Mon, 2009-03-02 at 22:26 +, Rob Taylor wrote: > > Brian J. Tarricone wrote: > > > Whether or not the object is local (in-process) or not is > > > irrelevant. Whether or not the method call is sync or async is > > > also irrelevant. It's a method call, pure and simple. DBus > > > itself even calls them method calls. All you're doing by > > > avoiding that in the IDL is making us learn and remember yet > > > another confusing and incompatible syntax. > > > > Wow. No. > > > > That was the main insanity of CORBA. Hiding that something is IPC > > results in you thinking things are working one way when in fact > > they're working completely differently and subject to a load of > > unexpected failure modes. > > > > Other things to consider here is that hiding IPC can also result in > > hugely inefficient IPC because you end up designing a pretty API > > rather than efficient IPC. > > > > I could rant at length here about the various benefits of CORBA vs > > message bus. But suffice to say hiding that there's a message bus > > means you end up with CORBA again and all the attendant problems. > > I very very much agree. And I had to fight these CORBA problems for > many years maintaining a bonobo based application. Please learn from > history and don't fuck up our platform again. > > This should be required reading for everyone that ever touches IPC: > http://research.sun.com/techrep/1994/abstract-29.html Ok, I'm convinced. Sorry for the noise. (That's an excellent read: short and clear, but still very thorough.) However, I'm still not convinced that the IDL for this should be some weird C-like syntax that makes everything look like messages rather than method calls. In fact, that paper you reference even notes that interfaces can still be defined using a 'normal' IDL, and then the parser would generate implementation based on whether or not the access model is intended to be local or remote, tailored for that access model. And if we still absolutely must use a weird message-like syntax, then why use a C-like syntax at all? Seems like it would be less confusing just to invent something new, or reuse something that already exists as to describe message-passing interfaces. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: DBus IDL (Was Re: GLib plans for the next cycle)
On Mon, 2009-03-02 at 22:26 +, Rob Taylor wrote: > Brian J. Tarricone wrote: > > Whether or not the object is local (in-process) or not is irrelevant. > > Whether or not the method call is sync or async is also irrelevant. It's > > a method call, pure and simple. DBus itself even calls them method > > calls. All you're doing by avoiding that in the IDL is making us learn > > and remember yet another confusing and incompatible syntax. > > Wow. No. > > That was the main insanity of CORBA. Hiding that something is IPC > results in you thinking things are working one way when in fact they're > working completely differently and subject to a load of unexpected > failure modes. > > Other things to consider here is that hiding IPC can also result in > hugely inefficient IPC because you end up designing a pretty API rather > than efficient IPC. > > I could rant at length here about the various benefits of CORBA vs > message bus. But suffice to say hiding that there's a message bus means > you end up with CORBA again and all the attendant problems. I very very much agree. And I had to fight these CORBA problems for many years maintaining a bonobo based application. Please learn from history and don't fuck up our platform again. This should be required reading for everyone that ever touches IPC: http://research.sun.com/techrep/1994/abstract-29.html Its as true today as it was when it was written (1994!). This is also a nice starting point for similar ideas: http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: DBus IDL (Was Re: GLib plans for the next cycle)
Hi Brian, Thanks for your reply, >> I understand that there is no difference on-the-wire between a >> function-call and message passing. The difference is in peoples >> perceptions and expectations. >> >> When I read CORBA IDL and see: >> >> int AFunction (int, int); >> >> Because of the connotations provided to me by years of procedural >> languages I expect this function call to be synchronous. I hope to break >> these perceptions by providing a message-based IDL. > > I don't have this perception; I think you're mistaking your own > perceptions for the majority's. Possibly. I can only go on what I've experienced though. For example the function supplied above when written in CORBA IDL DOES map to a synchronous function call. To make the above call async one has to use the 'oneway' modifier. So the people that wrote the CORBA IDL had the same expectations as me. > > One of the huge benefits of this entire exercise is to "hide" dbus calls > and make them look like methods on an object. If you're going to avoid > calling dbus methods "methods," then I fail to see the point. Its not my intention to 'hide' dbus calls. Although one could write an IDL and IPC libraries like this (CORBA did something similar) I think its better to write a language that just describes message formats specific to D-Bus. You might not have use for it, but I think it will be very useful to a project I am working on. > > Whether or not the object is local (in-process) or not is irrelevant. Really don't agree. > Whether or not the method call is sync or async is also irrelevant. It's > a method call, pure and simple. DBus itself even calls them method > calls. All you're doing by avoiding that in the IDL is making us learn > and remember yet another confusing and incompatible syntax. I don't think its a good idea to avoid calling the messages 'methods'. Its what the D-Bus specification calls them, so I'll stick with it. > > I ask you to *please* reconsider not using some normal method-call > syntax for the IDL. There's really no reason to do otherwise. If there > really is a perception problem, people need to fix that on their own. I'm fairly sure that what I'm doing here is correct. But I'll admit it does move away from the syntax comfort zone. There really isn't that much to learn with an IDL, its not a programming language, so people should be able to pick up the one moderately new thing fairly quickly. > > -brian > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list Thanks Mark ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: DBus IDL (Was Re: GLib plans for the next cycle)
Brian J. Tarricone wrote: > Mark Doffman wrote: > >> I understand that there is no difference on-the-wire between a >> function-call and message passing. The difference is in peoples >> perceptions and expectations. >> >> When I read CORBA IDL and see: >> >> int AFunction (int, int); >> >> Because of the connotations provided to me by years of procedural >> languages I expect this function call to be synchronous. I hope to break >> these perceptions by providing a message-based IDL. > > I don't have this perception; I think you're mistaking your own > perceptions for the majority's. > > One of the huge benefits of this entire exercise is to "hide" dbus calls > and make them look like methods on an object. If you're going to avoid > calling dbus methods "methods," then I fail to see the point. I think you're confusing describing the wire format of a message bus protocol with language bindings. Personally I would like to avoid that confusion which caused a good few problems in the CORBA days. > Whether or not the object is local (in-process) or not is irrelevant. > Whether or not the method call is sync or async is also irrelevant. It's > a method call, pure and simple. DBus itself even calls them method > calls. All you're doing by avoiding that in the IDL is making us learn > and remember yet another confusing and incompatible syntax. Wow. No. That was the main insanity of CORBA. Hiding that something is IPC results in you thinking things are working one way when in fact they're working completely differently and subject to a load of unexpected failure modes. Other things to consider here is that hiding IPC can also result in hugely inefficient IPC because you end up designing a pretty API rather than efficient IPC. I could rant at length here about the various benefits of CORBA vs message bus. But suffice to say hiding that there's a message bus means you end up with CORBA again and all the attendant problems. > I ask you to *please* reconsider not using some normal method-call > syntax for the IDL. There's really no reason to do otherwise. If there > really is a perception problem, people need to fix that on their own. Thanks, Rob > -brian > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Rob Taylor, Codethink Ltd. - http://codethink.co.uk ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: DBus IDL (Was Re: GLib plans for the next cycle)
Mark Doffman wrote: I understand that there is no difference on-the-wire between a function-call and message passing. The difference is in peoples perceptions and expectations. When I read CORBA IDL and see: int AFunction (int, int); Because of the connotations provided to me by years of procedural languages I expect this function call to be synchronous. I hope to break these perceptions by providing a message-based IDL. I don't have this perception; I think you're mistaking your own perceptions for the majority's. One of the huge benefits of this entire exercise is to "hide" dbus calls and make them look like methods on an object. If you're going to avoid calling dbus methods "methods," then I fail to see the point. Whether or not the object is local (in-process) or not is irrelevant. Whether or not the method call is sync or async is also irrelevant. It's a method call, pure and simple. DBus itself even calls them method calls. All you're doing by avoiding that in the IDL is making us learn and remember yet another confusing and incompatible syntax. I ask you to *please* reconsider not using some normal method-call syntax for the IDL. There's really no reason to do otherwise. If there really is a perception problem, people need to fix that on their own. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Mon, Mar 2, 2009 at 3:40 AM, Mark Doffman wrote: > Hello Everyone, I think the DBus list would be interested too. > I feel that the D-Bus introspection XML is used badly. For writing a > D-Bus specification there is too little information to understand a > protocol. Although numerous extensions have been made (Qt, EggDBus, > Telepathy) these are all incompatible. Right. > The immediate criticism I imagine I will face when creating a D-Bus IDL > is that we are re-creating CORBA. Well, CORBA is a lot of things. Some good[1], some bad[2], and some completely insane[3]. > This is not the case. The D-Bus IDL > has NO defined mapping into language bindings. They serve only to > provide readable documentation for a D-Bus protocol. They may also help > language bindings, providing hints as to how the protocol should be mapped. A key question to consider is - do you plan for software to install this IDL into a well-known location? Should the ConsoleKit-devel package come with IDL instead of the dbus-glib XML in /usr/share/dbus-1/interfaces it has now? If not, why not? If so, then I think it makes sense to consider using it for at least statically typed bindings. In other words the goal should be to replace the various XML formats as much as possible. Also, some prior work: http://lists.freedesktop.org/archives/dbus/2004-March/000817.html [1] The IDL was generally OK [2] Bindings weren't very good, though I guess we share this problem with DBus [3] Trying to unify in-process invocation vs out of process vs on the network ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
DBus IDL (Was Re: GLib plans for the next cycle)
Hi Havoc, Thanks for the reply. I have also changed the subject of this which I should have done in the initial e-mail. > Hi, > > On Mon, Mar 2, 2009 at 3:40 AM, Mark Doffman > wrote: >> Both the throws and reply clauses are optional, but if a method does not >> have a reply it should not have a throws clause. > > This is perhaps a misunderstanding. All methods have replies (in the > wire protocol). You may choose to ignore or not wait for the reply, if > you don't need confirmation that the method message was received and > handled. > > This should *not* be in an interface description. For a given method, > one client can call it and wait for reply, and another client can call > it and ignore the reply. This is just up to the method caller whether > to do this. But all methods can be invoked in both ways. > > Whether to block for reply is an example of a hint needed for static > code generation, that is not part of the interface description. I > would recommend handling this as a command line switch or similar on > the code generation tool. > > There is a flag on messages that senders can set to indicate they do > not intend to wait for a reply; this is just an optimization. But note > it is per-message, not per-message-type. I take your points completely. Details of waiting for a reply or not should not be in the interface description. Details of whether to set a method call as 'no-reply' should not be in this IDL. When describing this IDL, and in the design, I imagined that all methods that did not specify a reply should be mapped to a "no-reply" call and all methods that did specify a reply should generally be sent asynchronously, but that this would be down to the binding. I now realize that this is wrong, all notions of how the message are sent should be binding specific, and provided in hints elsewhere if necessary. The IDL should only specify the format of the message and optionally the format of the reply. If no reply format is specified the reply is assumed empty. > >> Probably the most controversial element of this syntax is that methods >> are not described using normal method syntax. This is to make utterly >> explicit that D-Bus methods are nothing more than a message type. And >> D-Bus nothing more than a message passing system. This IDL is describing >> message types, not function call types. When I started using D-Bus the >> notation offooled me into thinking that D-Bus >> methods were function calls, and as such synchronous. I want no-one new >> to D-Bus to make that mistake again. > > This seems like a misunderstanding also. How do you think CORBA works? > It is the same on the wire; it sends some stuff over the socket to > make a method call, and unless you specify "oneway" (which is brokenly > in the IDL, rather than the code generator) it blocks and waits to > know if the method was processed. dbus is exactly the same. > > Whether to block is just a matter of whether you block. You can block > or not. If you block, you wait to get an "ack" back, possibly with > return values in it. If you don't block, then you fire-and-forget. > > *libdbus* which is one dbus implementation, encourages you not to > block, because I consider that more correct and in any case very > useful. But it does have APIs suitable for blocking as well, like > dbus_connection_send_with_reply_and_block(). > > Anyway, I think there is no difference between method calls and > message passing. The only difference is in whether the client side API > is made to look just like a native object. But that's totally > orthogonal to the IDL and to the wire protocol. I understand that there is no difference on-the-wire between a function-call and message passing. The difference is in peoples perceptions and expectations. When I read CORBA IDL and see: int AFunction (int, int); Because of the connotations provided to me by years of procedural languages I expect this function call to be synchronous. I hope to break these perceptions by providing a message-based IDL. Thanks Mark ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Hi, On Mon, Mar 2, 2009 at 3:40 AM, Mark Doffman wrote: > Both the throws and reply clauses are optional, but if a method does not > have a reply it should not have a throws clause. This is perhaps a misunderstanding. All methods have replies (in the wire protocol). You may choose to ignore or not wait for the reply, if you don't need confirmation that the method message was received and handled. This should *not* be in an interface description. For a given method, one client can call it and wait for reply, and another client can call it and ignore the reply. This is just up to the method caller whether to do this. But all methods can be invoked in both ways. Whether to block for reply is an example of a hint needed for static code generation, that is not part of the interface description. I would recommend handling this as a command line switch or similar on the code generation tool. There is a flag on messages that senders can set to indicate they do not intend to wait for a reply; this is just an optimization. But note it is per-message, not per-message-type. > Probably the most controversial element of this syntax is that methods > are not described using normal method syntax. This is to make utterly > explicit that D-Bus methods are nothing more than a message type. And > D-Bus nothing more than a message passing system. This IDL is describing > message types, not function call types. When I started using D-Bus the > notation offooled me into thinking that D-Bus > methods were function calls, and as such synchronous. I want no-one new > to D-Bus to make that mistake again. This seems like a misunderstanding also. How do you think CORBA works? It is the same on the wire; it sends some stuff over the socket to make a method call, and unless you specify "oneway" (which is brokenly in the IDL, rather than the code generator) it blocks and waits to know if the method was processed. dbus is exactly the same. Whether to block is just a matter of whether you block. You can block or not. If you block, you wait to get an "ack" back, possibly with return values in it. If you don't block, then you fire-and-forget. *libdbus* which is one dbus implementation, encourages you not to block, because I consider that more correct and in any case very useful. But it does have APIs suitable for blocking as well, like dbus_connection_send_with_reply_and_block(). Anyway, I think there is no difference between method calls and message passing. The only difference is in whether the client side API is made to look just like a native object. But that's totally orthogonal to the IDL and to the wire protocol. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Hello all,
There were some glaring errors in the example IDL I provided.
> On to the syntax:
>
> My idea for the IDL syntax is to remain close to the 'C' family of
> languages, and is most places to C#.
>
> Elements can be namespaced using:
>
> namespace {
>
> }
>
Should be:
namespace org.freedesktop {
}
> But this should not necessarily translate into a D-Bus interface.
>
> Interfaces are created by:
>
> interface {
>
> }
Should be:
interface atspi2 {
}
Also I left out the possibility of properties. Properites do not really
fit with my idea for this IDL. They are too high-level. But as they are
included in Qt, Telepathy and EggDBus they have to exist.
readable writable property PropName {
AStruct one;
uint32 two;
}
readable writable are optional. Default is to both.
Properties are difficult because the method of transport for the
properties is unknown. (Telepathy uses a different properties interface
I believe) The default should be org.freedesktop.DBus.Properties but
perhaps there needs to be an extension to specify the underlying interface.
Thanks
Mark
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Hi Mikkel
>
>>
>>
>>
>> Methods are declared by:
>>
>> method methodName {
>>enumName anenum;
>> } reply {
>>structName astruct;
>> } throws (ErrorOne, ErrorTwo);
>>
>
> If you are so keen on clearing out that this is not really a 'method' then
> why is it declared as such? Why not call it 'message'?
I have misgivings about calling it 'method'. The problem is that
'message' also refers to 'signal' and 'error'. 'method' is the name
given to these types of messages in the D-Bus spec, so it seems
reasonable for it to be the name in the IDL.
>
> Both the throws and reply clauses are optional, but if a method does not
>> have a reply it should not have a throws clause.
>>
>
> Is this a limitation of DBus or you spec or the IDL? It seems odd that
> methodTakingEnum(in i myEnum) can not return a DBus error if myEnum is out
> of range...
Not sure. I believe that its really a limitation of the libdbus
bindings. There is not an easy way to have an async method sent and
register a handler for an Error message. Good point though. There isn't
anything against it in the D-Bus specification so I retract that
statement. It now becomes:
Methods can have an optional reply or throws clause.
>
> And also; can we not call it something other than didl? It is impossible to
> google as there are already tonnes of didls - not to mention the infamous
> Diddl mouse that Google is pretty convinced that I am really wanting to
> search for (which may or may not be correct, but please don't go there) :-)
Point taken, name will be changed to something more googleable. Messdl?
(Message description language) Something more inventive anyone?
>
> Anyways I am really glad that someone is looking into this, but I also hope
> that we end up with only one IDL and not N > 1.
>
Thanks
Mark
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
2009/3/2 Mark Doffman
>
>
>
> Methods are declared by:
>
> method methodName {
>enumName anenum;
> } reply {
>structName astruct;
> } throws (ErrorOne, ErrorTwo);
>
If you are so keen on clearing out that this is not really a 'method' then
why is it declared as such? Why not call it 'message'?
Both the throws and reply clauses are optional, but if a method does not
> have a reply it should not have a throws clause.
>
Is this a limitation of DBus or you spec or the IDL? It seems odd that
methodTakingEnum(in i myEnum) can not return a DBus error if myEnum is out
of range...
And also; can we not call it something other than didl? It is impossible to
google as there are already tonnes of didls - not to mention the infamous
Diddl mouse that Google is pretty convinced that I am really wanting to
search for (which may or may not be correct, but please don't go there) :-)
Anyways I am really glad that someone is looking into this, but I also hope
that we end up with only one IDL and not N > 1.
--
Cheers,
Mikkel
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Hello Everyone,
There has been some discussion about an IDL for EggDBus. I have also
recently started working on a D-Bus IDL so would like to get some
feedback on the syntax and how well the IDL would fit when generating
EggDBus bindings.
I have been working on D-Bus AT-SPI and the IDL is born out of
frustration with the way in which this large and complex D-Bus protocol
is currently documented.
Suffice it to say that I agree with David; a D-Bus IDL is neccessary.
When I began the AT-SPI D-Bus project I did not hold this opinion and
thought that D-Bus XML with extensions was a reasonable way to define a
protocol. (We currently use Telepathy D-Bus XML) As its size is very
large this spec has become unreadable in XML, difficult to modify, and
will require some effort to translate into a decent documentation format.
I feel that the D-Bus introspection XML is used badly. For writing a
D-Bus specification there is too little information to understand a
protocol. Although numerous extensions have been made (Qt, EggDBus,
Telepathy) these are all incompatible. For someone like me, writing a
D-Bus specification that may be mapped to all of these it means
re-writing or adding extensions to the spec for all of the possible
bindings. This was not a valid solution. The D-Bus IDL will solve this,
providing a translator for the IDL into EggDBus XML, TelepathyXML and Qt
XML.
On to the syntax:
My idea for the IDL syntax is to remain close to the 'C' family of
languages, and is most places to C#.
Elements can be namespaced using:
namespace {
}
But this should not necessarily translate into a D-Bus interface.
Interfaces are created by:
interface {
}
The basic types of the IDL are those of D-Bus, for example uint32 & variant.
New types can be created using:
struct structName {
uint32 Name;
}
enum enumName {
VALUEONE = 1,
VALUETWO = 2,
}
typedef structName[][] ArrayOfArrayOfStructName;
Methods are declared by:
method methodName {
enumName anenum;
} reply {
structName astruct;
} throws (ErrorOne, ErrorTwo);
Both the throws and reply clauses are optional, but if a method does not
have a reply it should not have a throws clause.
Signals are declared using:
signal signalName {
structName astruct;
}
errors are similar:
error errorName {
structName astruct;
}
There should also be a 'using' statement that has similar properties to
the C# statement.
In general the design philosophy for the IDL is to provide the bare
minimum of added concepts on-top of D-Bus needed to document a D-Bus
protocol. These extra concepts are those of named errors, structs, enums
and named method and reply elements.
Specifically excluded are things like unions that could be mapped to
D-Bus in very many ways depending on the bindings.
Probably the most controversial element of this syntax is that methods
are not described using normal method syntax. This is to make utterly
explicit that D-Bus methods are nothing more than a message type. And
D-Bus nothing more than a message passing system. This IDL is describing
message types, not function call types. When I started using D-Bus the
notation offooled me into thinking that D-Bus
methods were function calls, and as such synchronous. I want no-one new
to D-Bus to make that mistake again.
The immediate criticism I imagine I will face when creating a D-Bus IDL
is that we are re-creating CORBA. This is not the case. The D-Bus IDL
has NO defined mapping into language bindings. They serve only to
provide readable documentation for a D-Bus protocol. They may also help
language bindings, providing hints as to how the protocol should be mapped.
When the IDL is (far) more complete the AT-SPI D-Bus protocol will be
translated into it. Currently there is an incomplete and bare grammar
available at git://git.codethink.co.uk/git/didl.git. The grammar is in
antlr3 format, so it is easy to generate a recognizer for it. There is
also the beginnings of an AST grammar.
I'd welcome all feedback on the syntax, and basic philosophy behind the
IDL. I'm very interested in translating into EggDBus XML as this will
make it easier to create new 'C' bindings for AT-SPI D-Bus. I'd like to
know if there is any information missing that would make this difficult.
There doesn't need to be one IDL to rule them all, people designing
D-Bus specifications are free to choose the format they like.
Thanks
Mark
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Hi, On Fri, Feb 13, 2009 at 10:35 AM, Matthias Clasen wrote: > > Not sure what that 'something else' would be on win32 or os x. Anyway, > dbus works fine on os x, as far as I know. And I think there is a > working win32 port around (even if it hasn't been merged back into > dbus proper yet). The win32 port is a little more "working" than working, and unmaintained because the people working on it were unhappy with my suggestions for getting the scare quotes off of "working" and decided to give up ... Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Hi, On Wed, Feb 11, 2009 at 1:07 AM, Matthias Clasen wrote: > There is also some work by Ryan Lortie on a Glib-compatible Dbus api > called gbus. It is lower-level than EggDbus, and might be suitable as a > replacement for libdbus. While I have no clear idea yet how EggDbus and > gbus will eventually relate, it is worth pointing out that EggDbus' use > of libdbus is an implementation detail that is not exposed in the api, > so it would be possible to replace it by something like gbus later on. I'm not sure this is realistic; it's sort of like saying GDK uses Xlib as an implementation detail so it could be replaced later on. While sort-of true, at the same time, a bunch of stuff would break. So you might want to go in with open eyes on this point. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote: > With 2.20 winding down, I think now would be a good time to talk about > what should happen in Glib 2.22. As has been discussed on bugzilla, I'd like to also get DNS resolving and network support into gio in the next release. Related bugs: http://bugzilla.gnome.org/show_bug.cgi?id=548466 http://bugzilla.gnome.org/show_bug.cgi?id=515973 I don't have an exact status update on the network part, but the resolver thing is imho ready to go in as is. The network i/o part has the right design and just needs some reviewing of details. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote: > - Where do we put this ? Inside libgobject (since it is more or less > DBus bindings for GObject) or inside libgio (since it uses the GIO async > pattern and some utility classes from GIO) or separate ? > >My proposal: Add it as a separate library, next to (or actually on > top of) GObject and GIO. Maybe call it GBus. Would Gtk+ link (directly) to this library? If so, we add one more library to the dynamic symbol name resolve cost for all applications using gtk+. I've spent a lot of time trying to remove such costs in apps... However, i understand where its comming from, since this is a "mostly used in unix" kind a library which we may not want to force all platforms to always use... Its a tricky issue... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Matthias Clasen schrieb: > On Fri, Feb 13, 2009 at 11:52 AM, Stefan Kost wrote: >> hi, >> Matthias Clasen schrieb: >>> With 2.20 winding down, I think now would be a good time to talk about >>> what should happen in Glib 2.22. >> What about >> http://bugzilla.gnome.org/show_bug.cgi?id=348080 >> "GObject property bindings like in libexo" >> >> there is a patch attached. This is one of the feature that people comming >> from >> the qt camp miss in the g-world. >> > > I have not looked at the patch in any detail yet. It is certainly > refreshing that it only needs 6 symbols. > > > + * Bindings work by automatically connecting to the "notify" signal on the > + * relevant properties. Keep in mind that this means property update > propagation > + * is not instantaneous and may not be thread-safe. > > I don't understand this. Why does this comment seem to imply that > property change notification and signals are non-instantaneous or not > threadsafe ? thread-safety: Lets assume one binds a data object A to a gtk widget B and data object A spawns a thread the sets the bound property on A, that would cause a redraw of the widget from that thread. non-instantaneous: the statement is proably there to point out that this is using signal sinternaly and thus depend on the ainloop beeing running (if I am not mistaken). > > + * Mutual binding creates a bidirectional link between two properties, > + * such that when either is updated, the other will likewise be updated. > + * Binding is internally prevented from being recursive between objects, > + * so that binding multiple objects and properties in complex ways > + * is possible. > > This is certainly not enough detail to actually use this in 'complex > ways' and have any confidence in what it does... For bidirectional links it blocks the signal emission for the handler of the opposite direction when setting the value to avoid creating a loop. This is one benefit of the api, as this is easy to get wrong in a application. > > I guess I'll have to look at the patch some more... > > > Matthias Thanks for reviewing it! Stefan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
From: "Vincent Untz", Date: 14/02/2009 01:25 : > Le mercredi 11 février 2009, à 11:31 +, Alberto Ruiz a écrit : >> 2009/2/11 Matthias Clasen ;: >>> This would allow us to move forward with several things in GTK+ that >>> will work much better if they can use DBus: >>> - session support >>> - unique application support >> Would DBus be swappable here for something else on non freedesktop >> environments? (Windows, Mac) > In the end I don't expect the use of dbus in the rest of the glib/gtk+ > stack API to be visible (but maybe I'm naive here). Might this be the next step towards getting the N in GNOME...? Why can't an application export a sub-set of its widgets and actions over D-Bus/Bonobo with little more than a couple waves of a GTK helper function? I understand that more advanced D-Bus functionality would still require specific handling, but basic functionality for all widgets could be provided through a standard "network interface" attached to GtkWidget, requiring only that the widget (and possibly its parents) be named and "enabled" (possibly though a flags-like functionality mask). Fredderic___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Fri, Feb 13, 2009 at 11:52 AM, Stefan Kost wrote: > hi, > Matthias Clasen schrieb: >> With 2.20 winding down, I think now would be a good time to talk about >> what should happen in Glib 2.22. > > What about > http://bugzilla.gnome.org/show_bug.cgi?id=348080 > "GObject property bindings like in libexo" > > there is a patch attached. This is one of the feature that people comming from > the qt camp miss in the g-world. > I have not looked at the patch in any detail yet. It is certainly refreshing that it only needs 6 symbols. + * Bindings work by automatically connecting to the "notify" signal on the + * relevant properties. Keep in mind that this means property update propagation + * is not instantaneous and may not be thread-safe. I don't understand this. Why does this comment seem to imply that property change notification and signals are non-instantaneous or not threadsafe ? + * Mutual binding creates a bidirectional link between two properties, + * such that when either is updated, the other will likewise be updated. + * Binding is internally prevented from being recursive between objects, + * so that binding multiple objects and properties in complex ways + * is possible. This is certainly not enough detail to actually use this in 'complex ways' and have any confidence in what it does... I guess I'll have to look at the patch some more... Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
hi, Matthias Clasen schrieb: > With 2.20 winding down, I think now would be a good time to talk about > what should happen in Glib 2.22. What about http://bugzilla.gnome.org/show_bug.cgi?id=348080 "GObject property bindings like in libexo" there is a patch attached. This is one of the feature that people comming from the qt camp miss in the g-world. Stefan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Matthias Clasen wrote: > On Fri, Feb 13, 2009 at 10:25 AM, Vincent Untz wrote: >> In the end I don't expect the use of dbus in the rest of the glib/gtk+ >> stack API to be visible (but maybe I'm naive here). ... > That being said, I'd expect that at least for some of the anticipated > use cases of dbus (unique appllications, session client) there will be > native apis on other platforms that GTK+ apis would wrap, instead of a > dbus-based implementation. Yeah. EggSMClient uses D-Bus (optionally) on linux, but the Windows and OS X backends use win32/carbon APIs. -- Dan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Fri, Feb 13, 2009 at 10:25 AM, Vincent Untz wrote: >> Would DBus be swappable here for something else on non freedesktop >> environments? (Windows, Mac) > > Just wondering if an easy way like "make this API UNIX-only" is an > option that can be considered? > > In the end I don't expect the use of dbus in the rest of the glib/gtk+ > stack API to be visible (but maybe I'm naive here). Not sure what that 'something else' would be on win32 or os x. Anyway, dbus works fine on os x, as far as I know. And I think there is a working win32 port around (even if it hasn't been merged back into dbus proper yet). That being said, I'd expect that at least for some of the anticipated use cases of dbus (unique appllications, session client) there will be native apis on other platforms that GTK+ apis would wrap, instead of a dbus-based implementation. But I haven't done any actual research on this... Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Le mercredi 11 février 2009, à 11:31 +, Alberto Ruiz a écrit : > 2009/2/11 Matthias Clasen : > > With 2.20 winding down, I think now would be a good time to talk about > > what should happen in Glib 2.22. > > > > One thing that has been tossed around for a long time is that it would > > be really good to have DBus support on the Glib level. > > Would this support be optional? I'm concerned about making GLib > dependant on a dbus development environment on Windows as DBus has no > regular windows builds whatsoever (AFAIK). > > > This would allow us to move forward with several things in GTK+ that > > will work much better if they can use DBus: > > - session support > > - unique application support > > Would DBus be swappable here for something else on non freedesktop > environments? (Windows, Mac) Just wondering if an easy way like "make this API UNIX-only" is an option that can be considered? In the end I don't expect the use of dbus in the rest of the glib/gtk+ stack API to be visible (but maybe I'm naive here). Vincent -- Les gens heureux ne sont pas pressés. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Wed, 2009-02-11 at 09:56 +, Ross Burton wrote: > On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote: > > - Where do we put this ? Inside libgobject (since it is more or less > > DBus bindings for GObject) or inside libgio (since it uses the GIO > > async > > pattern and some utility classes from GIO) or separate ? > > > >My proposal: Add it as a separate library, next to (or actually on > > top of) GObject and GIO. Maybe call it GBus. > > Would it be possible for the dbus GLib main loop integration and the > GObject bridging to be separate libraries? Having DBus integrated in > glib-only applications would be useful, and also it lets you re-use the > main loop binding if you don't want to use GBus. Not sure how this is possible; the fact that EggDBus is using libdbus-1 is an implementation detail and I think we want it to stay that way. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Am Mittwoch, den 11.02.2009, 11:31 + schrieb Alberto Ruiz: > 2009/2/11 Matthias Clasen : > > With 2.20 winding down, I think now would be a good time to talk about > > what should happen in Glib 2.22. > > > > One thing that has been tossed around for a long time is that it would > > be really good to have DBus support on the Glib level. > > Would this support be optional? I'm concerned about making GLib > dependant on a dbus development environment on Windows as DBus has no > regular windows builds whatsoever (AFAIK). > > > This would allow us to move forward with several things in GTK+ that > > will work much better if they can use DBus: > > - session support > > - unique application support > > Would DBus be swappable here for something else on non freedesktop > environments? (Windows, Mac) Well, probably we should first answer the questions if Windows and OSX provide APIs which could serve as drop-in replacement for DBus. No idea what's available on OSX. For Windows I wonder if it's really possible to seamlessly emulate DBus via COM. DBus is quite dynamic, maybe the IDispatch interface[1] comes close? Otherwise, if those platforms don't have a proper drop-in replacement it probably would be more reasonable to really use DBus even on those platforms. Ciao, Mathias [1] http://msdn.microsoft.com/en-us/library/ms221608.aspx -- Mathias Hasselmann Personal Blog: http://taschenorakel.de/mathias/ Openismus GmbH: http://www.openismus.com/ -- Mathias Hasselmann Personal Blog: http://taschenorakel.de/mathias/ Openismus GmbH: http://www.openismus.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote: > - What do we do about collections ? EggDbus adds typesafe GObject > wrappers around GHashTable and GArray. Other people have grandiose plans > to force java/.net style collection interfaces into GObject. You are using the phrase "To force". Is this an indication that you personally don't like such collection APIs? If so, can you explain why? > My proposal: Dodge the issue by just adding the minimal necessities > to GObject: a type for GArray (GHashTable already has one), and an api > to associate element type information to arrays and hash tables. Applications may have different requirements for a collection API: o. Separate interface from implementation o. The current GLib datatypes are hard to use - no reference counting - no type information (GType and memory management) Although your proposal addresses the latter and makes sense for EggDBus's requirements, I don't see how it addresses the former. We have started a git branch that implements the proposal in gobject/. http://git.codethink.co.uk/?p=glib;a=shortlog;h=collections We are open to comments and proposals from the community. We plan to implement use-cases, like a GTreeModel, on top of this, at some point. Next to model-viewing widgets we have many other use-cases with which we will be experimenting in this git repo. Why is it an advantage to separate implementation from interface? First, why do we want one interface instead of many: - If you provide an API where you use a collection, it's important that when you change the implementation (of the collection), that your API doesn't have to change with it. This is a similar issue to Gtk+ exposing a lot implementation details in its API. - Bindings. Collection are usually bound in a special way to integrate with a higher language. - Consistency of the API. This makes it easier for app developers. Here's a list of examples with existing collection-like-apis: GVariant, GHashTable, G(S)List, GPtrArray, GArray, ... If we add a few (significant) libraries to the list, we get: Gtk+ : GtkTreeModel Clutter : ClutterModelIter Gee (Vala): GeeIterator, GeeIterable GStreamer : GstIterator Camel : CamelIterator EDS : EIterator Tinymail : TnyIterator, TnyIterable LibAnjuta : IAnjutaIterable This is the proposal, by the way: http://live.gnome.org/IteratorsAPI > When I sat down with David and tried to figure out what the minimal > necessities actually are, we came up with the following: > GLib GObject > > g_ptr_array_ref/unref > g_ptr_array_set_data > g_ptr_array_set_element_free_func >G_TYPE_PTR_ARRAY >g_ptr_array_set/get_element_type > > g_array_ref/unref > g_array_set_data > g_array_get_element_size >G_TYPE_ARRAY >g_array_set/get_element_type >g_array_new_with_type > >g_hash_table_set/get_key_type >g_hash_table_set/get_value_type >g_hash_table_new_with_types Greetings, Jürg and Philip (at a codecamp) -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
2009/2/11 Matthias Clasen : > With 2.20 winding down, I think now would be a good time to talk about > what should happen in Glib 2.22. > > One thing that has been tossed around for a long time is that it would > be really good to have DBus support on the Glib level. Would this support be optional? I'm concerned about making GLib dependant on a dbus development environment on Windows as DBus has no regular windows builds whatsoever (AFAIK). > This would allow us to move forward with several things in GTK+ that > will work much better if they can use DBus: > - session support > - unique application support Would DBus be swappable here for something else on non freedesktop environments? (Windows, Mac) > Let me list some, with possible answers: -- Cheers, Alberto Ruiz ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote: > - Where do we put this ? Inside libgobject (since it is more or less > DBus bindings for GObject) or inside libgio (since it uses the GIO > async > pattern and some utility classes from GIO) or separate ? > >My proposal: Add it as a separate library, next to (or actually on > top of) GObject and GIO. Maybe call it GBus. Would it be possible for the dbus GLib main loop integration and the GObject bridging to be separate libraries? Having DBus integrated in glib-only applications would be useful, and also it lets you re-use the main loop binding if you don't want to use GBus. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
Hi, On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote: > A while ago David put forward his work on EggDbus and wrote a very > detailed mail [1] with arguments for why it would be very good to have > DBus support on the Glib level, why dbus-glib is not good enough, and > how his EggDbus bindings work. His approach seemed to be well-received, > and I'd like to propose that we take a serious look at integrating > EggDbus in GLib 2.22. A few words on work planned for EggDBus relative to the announcement I made back in December - Revisit marshaling (EggDBusMessage mainly) so it's easier to use directly from language bindings. At the same time verify that something like Ryan's GBus driver code can be swapped in. - Fix up struct handling; it's a bit messy right. Also want to support also support generating POD C structs (registered with the type system) for applications that wants to trade encapsulation / sealing for performance. Most of the ground work for this is already done. - An IDL language to avoid having to use D-Bus introspection XML to describe interfaces / structs / enums / flags / error domains. I just started on this. Ideally we can standardize such an IDL language on the D-Bus list but it shouldn't be a blocker for GLib inclusion. - Probably make it possible (via annotations in the IDL language) to describe what C containers to use (e.g. GPtrArray vs GList). - Ideally make it easy to add backends to the bindings generator so e.g. C++ or Java or whatever language can be generated. Some people would argue, and I am one of them, that this is even useful for dynamic languages. Of course YMMV. - Peer to peer connections. Ideally I want to use the GNIO stuff that is targeted for libgio (as far as I understand). Haven't looked into this at all. - Generate Docbook describing the D-Bus interfaces / structs / enums / flags / error domains defined in the introspection XML / IDL. This is basically done, see http://people.freedesktop.org/~david/polkit-0.91/docs/ref-dbus-api.html for an example of where I use it in PolicyKit. None of these are big-ticket items and I consider all of them essential for GLib inclusion. David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib plans for the next cycle
With 2.20 winding down, I think now would be a good time to talk about what should happen in Glib 2.22. One thing that has been tossed around for a long time is that it would be really good to have DBus support on the Glib level. This would allow us to move forward with several things in GTK+ that will work much better if they can use DBus: - session support - unique application support A while ago David put forward his work on EggDbus and wrote a very detailed mail [1] with arguments for why it would be very good to have DBus support on the Glib level, why dbus-glib is not good enough, and how his EggDbus bindings work. His approach seemed to be well-received, and I'd like to propose that we take a serious look at integrating EggDbus in GLib 2.22. There is also some work by Ryan Lortie on a Glib-compatible Dbus api called gbus. It is lower-level than EggDbus, and might be suitable as a replacement for libdbus. While I have no clear idea yet how EggDbus and gbus will eventually relate, it is worth pointing out that EggDbus' use of libdbus is an implementation detail that is not exposed in the api, so it would be possible to replace it by something like gbus later on. Of course, assuming we can agree on that having DBus support inside Glib is a good idea, there are still going to be some contentious questions. Let me list some, with possible answers: - Where do we put this ? Inside libgobject (since it is more or less DBus bindings for GObject) or inside libgio (since it uses the GIO async pattern and some utility classes from GIO) or separate ? My proposal: Add it as a separate library, next to (or actually on top of) GObject and GIO. Maybe call it GBus. - What do we do about the added 16bit integer types that are supported by the DBus protocol, but don't have corresponding fundamental types in GObject ? EggDbus currently has fundamental types for them. My proposal: Just add the fundamental types to GObject. It would be odd to ship fundamental types spread over several libraries, and int16 is really not worth fighting against... - What do we do about collections ? EggDbus adds typesafe GObject wrappers around GHashTable and GArray. Other people have grandiose plans to force java/.net style collection interfaces into GObject. My proposal: Dodge the issue by just adding the minimal necessities to GObject: a type for GArray (GHashTable already has one), and an api to associate element type information to arrays and hash tables. When I sat down with David and tried to figure out what the minimal necessities actually are, we came up with the following: GLib GObject g_ptr_array_ref/unref g_ptr_array_set_data g_ptr_array_set_element_free_func G_TYPE_PTR_ARRAY g_ptr_array_set/get_element_type g_array_ref/unref g_array_set_data g_array_get_element_size G_TYPE_ARRAY g_array_set/get_element_type g_array_new_with_type g_hash_table_set/get_key_type g_hash_table_set/get_value_type g_hash_table_new_with_types Comments ? Matthias [1] http://mail.gnome.org/archives/gtk-devel-list/2008-December/msg00059.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
