GLib plans for the next cycle

classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

GLib plans for the next cycle

Matthias Clasen-2
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

David Zeuthen
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Ross Burton
In reply to this post by Matthias Clasen-2
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: [hidden email]
                                          jabber: [hidden email]
                                           www: http://burtonini.com

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Alberto Ruiz-4
In reply to this post by Matthias Clasen-2
2009/2/11 Matthias Clasen <[hidden email]>:
> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Philip Van Hoof
In reply to this post by Matthias Clasen-2
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Mathias Hasselmann-2
In reply to this post by Alberto Ruiz-4
Am Mittwoch, den 11.02.2009, 11:31 +0000 schrieb Alberto Ruiz:

> 2009/2/11 Matthias Clasen <[hidden email]>:
> > 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 <[hidden email]>
Personal Blog: http://taschenorakel.de/mathias/
Openismus GmbH: http://www.openismus.com/
--
Mathias Hasselmann <[hidden email]>
Personal Blog: http://taschenorakel.de/mathias/
Openismus GmbH: http://www.openismus.com/

_______________________________________________
gtk-devel-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

David Zeuthen
In reply to this post by Ross Burton
On Wed, 2009-02-11 at 09:56 +0000, 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Vincent Untz
In reply to this post by Alberto Ruiz-4
Le mercredi 11 février 2009, à 11:31 +0000, Alberto Ruiz a écrit :

> 2009/2/11 Matthias Clasen <[hidden email]>:
> > 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Matthias Clasen-2
On Fri, Feb 13, 2009 at 10:25 AM, Vincent Untz <[hidden email]> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Dan Winship-2
Matthias Clasen wrote:
> On Fri, Feb 13, 2009 at 10:25 AM, Vincent Untz <[hidden email]> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Stefan Sauer-4
In reply to this post by Matthias Clasen-2
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Matthias Clasen-2
On Fri, Feb 13, 2009 at 11:52 AM, Stefan Kost <[hidden email]> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Freddie Unpenstein
In reply to this post by Matthias Clasen-2
From: "Vincent Untz", Date: 14/02/2009 01:25 :
> Le mercredi 11 février 2009, à 11:31 +0000, Alberto Ruiz a écrit :
>> 2009/2/11 Matthias Clasen <[hidden email]>;:

>>> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Stefan Sauer-4
In reply to this post by Matthias Clasen-2
Matthias Clasen schrieb:

> On Fri, Feb 13, 2009 at 11:52 AM, Stefan Kost <[hidden email]> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Alexander Larsson
In reply to this post by Matthias Clasen-2
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Alexander Larsson
In reply to this post by Matthias Clasen-2
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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Havoc Pennington-3
In reply to this post by Matthias Clasen-2
Hi,

On Wed, Feb 11, 2009 at 1:07 AM, Matthias Clasen
<[hidden email]> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Havoc Pennington-3
In reply to this post by Matthias Clasen-2
Hi,

On Fri, Feb 13, 2009 at 10:35 AM, Matthias Clasen
<[hidden email]> 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Mark Doffman
In reply to this post by Matthias Clasen-2
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 of <method> <arg/> </method> fooled 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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: GLib plans for the next cycle

Mikkel Kamstrup Erlandsen-2
2009/3/2 Mark Doffman <[hidden email]>
<SNIP>


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
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
1234