Libsoylent API

[Travis Reitter]

Here's my current line of thinking for the Libsoylent API.

We have a major choice between restricting the calling programs' access
to accessor ("get" someone's metadata) and mutator ("set"), constructor
(create a new person), and deconstructor [?] (delete a person)
functions, giving the caller an ID for each person; or actually
returning a SoylentPerson struct and letting the caller modify and
access people metadata there.

The first approach is more restrictive and would be slower (though it
probably wouldn't be significant), but would cleanly abstract some
details from the caller (for instance, a set function would directly
make evolution-data-server modify the existing database). The second
approach would require some synchronization (after modifying a
SoylentPerson struct, the caller would need to use a function to save
the changes to the database(s)).

I lean heavily toward the first approach.

***

I'm moving today, so I may not have Internet access for at least a few
days. By the time I do, though, I should be settled in and finally be
ready to devote some time to this project.

-Travis

_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Colin Barrett]

I definitely agree, the first way is the Right Way to do this. Go for  
it :)

- Colin

On Jun 19, 2005, at 10:48 AM, Travis Reitter wrote:

> Here's my current line of thinking for the Libsoylent API.
>
> We have a major choice between restricting the calling programs'  
> access
> to accessor ("get" someone's metadata) and mutator ("set"),  
> constructor
> (create a new person), and deconstructor [?] (delete a person)
> functions, giving the caller an ID for each person; or actually
> returning a SoylentPerson struct and letting the caller modify and
> access people metadata there.
>
> The first approach is more restrictive and would be slower (though it
> probably wouldn't be significant), but would cleanly abstract some
> details from the caller (for instance, a set function would directly
> make evolution-data-server modify the existing database). The second
> approach would require some synchronization (after modifying a
> SoylentPerson struct, the caller would need to use a function to save
> the changes to the database(s)).
>
> I lean heavily toward the first approach.
>
> ***
>
> I'm moving today, so I may not have Internet access for at least a few
> days. By the time I do, though, I should be settled in and finally be
> ready to devote some time to this project.
>
> -Travis
>
> _______________________________________________
> galago-devel mailing list
> galago-devel@...
> http://lists.freedesktop.org/mailman/listinfo/galago-devel
>
>

_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Kalle Vahlman]

On 6/19/05, Travis Reitter <treitter-dev@...> wrote:

> Here's my current line of thinking for the Libsoylent API.
>
> We have a major choice between restricting the calling programs' access
> to accessor ("get" someone's metadata) and mutator ("set"), constructor
> (create a new person), and deconstructor [?] (delete a person)
> functions, giving the caller an ID for each person; or actually
> returning a SoylentPerson struct and letting the caller modify and
> access people metadata there.
>
> The first approach is more restrictive and would be slower (though it
> probably wouldn't be significant), but would cleanly abstract some
> details from the caller (for instance, a set function would directly
> make evolution-data-server modify the existing database). The second
> approach would require some synchronization (after modifying a
> SoylentPerson struct, the caller would need to use a function to save
> the changes to the database(s)).

If the library is in C, then the C API is probably best to be
get/set-based. Any language bindings that have proper support for
objects could then implement object-y API with those (which can detect
errors on set/get or something like that).

It would sound a little too error prone to let the user modify a
struct directly in C, and would result in a messy error detection
code.

--
Kalle Vahlman, zuh@...
_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Nicolas Trangez]

On Mon, 2005-06-20 at 10:48 +0300, Kalle Vahlman wrote:

> On 6/19/05, Travis Reitter <treitter-dev@...> wrote:
> > Here's my current line of thinking for the Libsoylent API.
> >
> > We have a major choice between restricting the calling programs' access
> > to accessor ("get" someone's metadata) and mutator ("set"), constructor
> > (create a new person), and deconstructor [?] (delete a person)
> > functions, giving the caller an ID for each person; or actually
> > returning a SoylentPerson struct and letting the caller modify and
> > access people metadata there.
> >
> > The first approach is more restrictive and would be slower (though it
> > probably wouldn't be significant), but would cleanly abstract some
> > details from the caller (for instance, a set function would directly
> > make evolution-data-server modify the existing database). The second
> > approach would require some synchronization (after modifying a
> > SoylentPerson struct, the caller would need to use a function to save
> > the changes to the database(s)).
>
> If the library is in C, then the C API is probably best to be
> get/set-based. Any language bindings that have proper support for
> objects could then implement object-y API with those (which can detect
> errors on set/get or something like that).
>
> It would sound a little too error prone to let the user modify a
> struct directly in C, and would result in a messy error detection
> code.

Agree 100%
Not using get/set methods (if we allow -set ;)) would result in a
completely unusable mess, not able to write bindings for other
languages,...
If we'd go for GObjects (would we? IMHO its a great system) we're almost
forced to use -get/-set, and creating bindings to Python, Mono and maybe
other platforms/languages I'm not familiar with should be very easy.

Ikke

_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Kalle Vahlman]

On 6/20/05, Ikke <eikke@...> wrote:
> If we'd go for GObjects (would we? IMHO its a great system) we're almost
> forced to use -get/-set, and creating bindings to Python, Mono and maybe
> other platforms/languages I'm not familiar with should be very easy.

For the above reasons, I'd raise my hand if voted on GObjects.

Plus with the dbus-glib bindings you could export the objects ~unchanged ;)

--
Kalle Vahlman, zuh@...
_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Nicolas Trangez]

On Mon, 2005-06-20 at 12:55 +0300, Kalle Vahlman wrote:
> On 6/20/05, Ikke <eikke@...> wrote:
> > If we'd go for GObjects (would we? IMHO its a great system) we're almost
> > forced to use -get/-set, and creating bindings to Python, Mono and maybe
> > other platforms/languages I'm not familiar with should be very easy.
>
> For the above reasons, I'd raise my hand if voted on GObjects.
>
> Plus with the dbus-glib bindings you could export the objects ~unchanged ;)
Using DBUS implies we'd be using a daemon (or at least a service that can be activated).
The question is: do we want a daemon? This has been discussed on IRC
several time already, and IIRC there was some sort of agreement the
answer on this question is "no".

Anyway, regardless of this, I should look into the new dbus-glib stuff
ross and others did. If only Gentoo would switch to Dbus 3.x :(

Regards,

Ikke

_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Kenneth Østby-2]

I'm not sure if it really matters at all, but I'm agreeing too :)

One thing I'm pondering upon though, is if we should be able to export
whole groups, ref: the figure tree here:
http://galago.info/wiki/Project_Soylent/AbstractionLayer as some kind
of GObject.


On 6/20/05, Kalle Vahlman <kalle.vahlman@...> wrote:

> On 6/20/05, Ikke <eikke@...> wrote:
> > If we'd go for GObjects (would we? IMHO its a great system) we're almost
> > forced to use -get/-set, and creating bindings to Python, Mono and maybe
> > other platforms/languages I'm not familiar with should be very easy.
>
> For the above reasons, I'd raise my hand if voted on GObjects.
>
> Plus with the dbus-glib bindings you could export the objects ~unchanged ;)
>
> --
> Kalle Vahlman, zuh@...
> _______________________________________________
> galago-devel mailing list
> galago-devel@...
> http://lists.freedesktop.org/mailman/listinfo/galago-devel
>

_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Nicolas Trangez]

On Mon, 2005-06-20 at 12:31 +0200, Kenneth Østby wrote:
> I'm not sure if it really matters at all, but I'm agreeing too :)
>
> One thing I'm pondering upon though, is if we should be able to export
> whole groups, ref: the figure tree here:
> http://galago.info/wiki/Project_Soylent/AbstractionLayer as some kind
> of GObject.

http://developer.gnome.org/doc/API/2.0/glib/glib-N-ary-Trees.html

Ikke

_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Kalle Vahlman]

On 6/20/05, Ikke <eikke@...> wrote:

> On Mon, 2005-06-20 at 12:55 +0300, Kalle Vahlman wrote:
> > On 6/20/05, Ikke <eikke@...> wrote:
> > > If we'd go for GObjects (would we? IMHO its a great system) we're almost
> > > forced to use -get/-set, and creating bindings to Python, Mono and maybe
> > > other platforms/languages I'm not familiar with should be very easy.
> >
> > For the above reasons, I'd raise my hand if voted on GObjects.
> >
> > Plus with the dbus-glib bindings you could export the objects ~unchanged ;)
> Using DBUS implies we'd be using a daemon (or at least a service that can be activated).

For the record, I didn't want to imply anything, just make a note of
added value... :)

> The question is: do we want a daemon? This has been discussed on IRC
> several time already, and IIRC there was some sort of agreement the
> answer on this question is "no".

That doesn't rule out the possibility of a dbus-activated update of
user information (ie. dbus activates a service which just grabs the
pending messages, writes stuff to <wherever> and exits), but I feel
dirty just thinking about such kludge.

Anyways, the implementation should make it easy to do whatever is
deemed the most used case. For example, the dbus-bridge can be made
afterwards regardless of the API scheme used, (if need be) so it
should only be considered as a possible bonus.

NOTE: rest is OT for this list, reply privately for these

> Anyway, regardless of this, I should look into the new dbus-glib stuff
> ross and others did. If only Gentoo would switch to Dbus 3.x :(

Don't hold your breath, the .2x <> .3x API change was pretty huge (so
*every* app has to be ported). That said, the .3x should not change
too much before 1.0 so there's really no point to look at .2x for new
projects anymore (except the fact that every distro has .2x, which is
both great and not so great).

You can set up a .3x environment pretty easily (for session bus
testing, not system). Just build with '--prefix=/foo' and configure
the program you compile with 'PKG_CONFIG_PATH=/foo/lib/pkgconfig
./configure --prefix=/foo'. It should pick up the new versions and
then you can run the daemon by hand and set the
DBUS_SESSION_BUS_ADDRESS env var and it should work.

I have a script that runs the session bus and fires up some xterms
with proper environment if anyone's interested.

--
Kalle Vahlman, zuh@...
_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Christian Hammond]

On Mon, Jun 20, 2005 at 11:03:04AM +0200, Ikke wrote:
> Agree 100%
> Not using get/set methods (if we allow -set ;)) would result in a
> completely unusable mess, not able to write bindings for other
> languages,...
> If we'd go for GObjects (would we? IMHO its a great system) we're almost
> forced to use -get/-set, and creating bindings to Python, Mono and maybe
> other platforms/languages I'm not familiar with should be very easy.

We are using GObject. There's some very basic stub code in SVN. I'll
code some more on it when I actually get the time to do so :)

And yeah, set/gets are always the right way to do things for a public
API. Data abstraction is good, and in this case, necessary.

The model I've got here involves a public SoylentPerson we work
directly with, a SoylentPersonBackend interface, and future
implementations of that for e-d-s and kaddressbook. One public API,
two backends. There's no need for a daemon or modules or anything in
this case, really. The code should be kept fairly simple, I think.

I have diagrams.. I need to put them up sometime.

Christian

--
Christian Hammond         <>  The Galago Project
chipx86@...      <>  http://www.galago.info/
   As of next week, passwords will be entered in Morse code.


_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Kenneth Østby-2]

> We are using GObject. There's some very basic stub code in SVN. I'll
> code some more on it when I actually get the time to do so :)
>
Do we have a SVN repository for this project?

If so, what's the url to it, and how do we get access to it?

>
> I have diagrams.. I need to put them up sometime.
>
> Christian
>
> --
> Christian Hammond         <>  The Galago Project
> chipx86@...      <>  http://www.galago.info/
>    As of next week, passwords will be entered in Morse code.
>
>
> BodyID:68266596.2.n.logpart (stored separately)
>
> _______________________________________________
> galago-devel mailing list
> galago-devel@...
> http://lists.freedesktop.org/mailman/listinfo/galago-devel
>
>
>

_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Christian Hammond]

On Tue, Jun 21, 2005 at 10:32:17AM +0200, Kenneth ?stby wrote:
> > We are using GObject. There's some very basic stub code in SVN. I'll
> > code some more on it when I actually get the time to do so :)
> >
> Do we have a SVN repository for this project?
>
> If so, what's the url to it, and how do we get access to it?

svn co http://svn.galago.info/trunk/libsoylent

Christian

--
Christian Hammond         <>  The Galago Project
chipx86@...      <>  http://www.galago.info/
   Somebody told me how frightening it was how much topsoil we are losing
   each year, but I told that story around the campfire and nobody got scared.
      -- Bill Austin


_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Nicolas Trangez]

On Tue, 2005-06-21 at 01:37 -0700, Christian Hammond wrote:

> On Tue, Jun 21, 2005 at 10:32:17AM +0200, Kenneth ?stby wrote:
> > > We are using GObject. There's some very basic stub code in SVN. I'll
> > > code some more on it when I actually get the time to do so :)
> > >
> > Do we have a SVN repository for this project?
> >
> > If so, what's the url to it, and how do we get access to it?
>
> svn co http://svn.galago.info/trunk/libsoylent
>
> Christian

There is some problem with this, as I mentioned before:
AFAIK Soylent is a Gnome-related project. If we ever want it to go into
the Gnome core (the soylent libs and client-side apps) we'll need those
apps to be i18n'ized. And the gnome-i18n team only works in gnome-cvs.

_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Christian Hammond]

On Tue, Jun 21, 2005 at 10:54:30AM +0200, Ikke wrote:

> On Tue, 2005-06-21 at 01:37 -0700, Christian Hammond wrote:
> > On Tue, Jun 21, 2005 at 10:32:17AM +0200, Kenneth ?stby wrote:
> > > > We are using GObject. There's some very basic stub code in SVN. I'll
> > > > code some more on it when I actually get the time to do so :)
> > > >
> > > Do we have a SVN repository for this project?
> > >
> > > If so, what's the url to it, and how do we get access to it?
> >
> > svn co http://svn.galago.info/trunk/libsoylent
> >
> > Christian
>
> There is some problem with this, as I mentioned before:
> AFAIK Soylent is a Gnome-related project. If we ever want it to go into
> the Gnome core (the soylent libs and client-side apps) we'll need those
> apps to be i18n'ized. And the gnome-i18n team only works in gnome-cvs.

It should not be a GNOME-specific project. Related is fine, but we
should not tie ourselves to one desktop. GNOME is not the only desktop
out there, and if we make ourselves dependant on GNOME, we lose the
ability to become a de facto standard that any app can use. I don't
believe in choosing sides when it's just as easy to play with both.

There are other i18n groups that will work with our svn tree. Look at
what gstreamer does, for example.

Christian

--
Christian Hammond         <>  The Galago Project
chipx86@...      <>  http://www.galago.info/
   Do not meddle in the affairs of wizards, for they are subtle and quick
   to anger.
      -- "The Fellowship of the Ring", J.R.R. Tolkien


_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Travis Reitter]

I like what everyone's been saying - the plans sound good.

Now the bad news: I'm going to cop-out and wait until Christian gets
back from vacation next week to do any more work - I could stumble
around trying to learn glib's nuances and so on, but I think it's better
I just put things off for another week or so and work together on it.
It'd be a much more efficient use of time.

Say it with me, everybody - Real Soon Now! :)

-Travis

_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel

[Christian Hammond]

On Wed, Jun 29, 2005 at 09:34:57PM -0700, Travis Reitter wrote:
> I like what everyone's been saying - the plans sound good.
>
> Now the bad news: I'm going to cop-out and wait until Christian gets
> back from vacation next week to do any more work - I could stumble
> around trying to learn glib's nuances and so on, but I think it's better
> I just put things off for another week or so and work together on it.
> It'd be a much more efficient use of time.
>
> Say it with me, everybody - Real Soon Now! :)

I'm back! But here's my problem. I still have a lot to do over the
next two weeks at work, and on top of that, I have to get a lot of
galago and notification stuff done before a presentation at SVLUG on
August 3rd. So, I won't have much time this month to work on any of
this. I'll probably know how much time I'll have after next week.

Christian

--
Christian Hammond         <>  The Galago Project
chipx86@...      <>  http://www.galago.info/
   Hey! It compiles! Ship it!


_______________________________________________
galago-devel mailing list
galago-devel@...
http://lists.freedesktop.org/mailman/listinfo/galago-devel