[Soylent-devel] Comments on API proposal

[mikkel kamstrup gmail com (Mikkel Kamstrup Erlandsen)]

2008/6/19 Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> Hi Soylenteers,
>
> A little greeting from the Xesam camp regarding the posted Soylent API
> proposal http://lists.codethink.co.uk/pipermail/soylent-devel/2008-June/000027.html.
>
> I hope this does not come out as to negative. I am really exited about
> your project.
>
> --- Local Database ---
> This sounds like a bad idea to me (sorry to put it bluntly). I can not
> see why a single one of your ideas can not be done over an abstracted
> backend. For example Xesam is going to define writing of metadata
> attributes in the next iteration.
>
> Just a bit of introspective methods to your abstract backend
> interface. Like can_write() in some way or other.
>
> Also, to just clear up - you want to add a local database but also talk to EDS?
>
> === SoylentPerson ===
> Maybe I propose that you consider including structs as a value type as
> well. In our work on the Xesam ontology we have realized that things
> blow up considerably if you don't do structs. Consider the case of
> geotagging, vcard allows you to geotag individual addresses, so if you
> have two fields 'homeAddress' and 'workAddress' then you need to
> introduce _four_ new fields for geo tags, homeGeoN, homeGeoE,
> workGeoN, workGeoE. Applying this problem in various places will very
> quickly become ugly.
>
> Structs incur the additional problem of having a way to query the
> struct members of course, but this is not a biggie in most set ups.
>
>  --- Attributes ---
> I can certainly understand that you want to be vCard compatible, but
> please do consider using the Xesam ontology. We are currently looking
> at ways to improve our vCard compatibility and the ontology is not
> finalized yet so you can still have a say if you are interested.
>
> Person.get_photo() - should this not return a GFile* instead?
>
> === SoylentGroup ===
>
>>> how should groups be stored. GConf?
>
> I am not sure how you are going to use groups, but as I guess they can
> easily contain 50-100 people (or more), which might not be a good idea
> to stickc in gconf?
>
> More over you might want to be able to query group memberships and
> relations efficiently.
>
>
> == Generally ==
> I think that it is a shame that you have not looked more into Xesam,
> because we have worked a lot on things very related to the stuff here.
> In addition to that a Xesam store would also allow for a very rich
> query interface that could take us past the "standard address book".
>
> More over I think it is really important we make sure that next
> generation Gnome components are future proof, extensible, and
> flexible. This is needed if we want to make sure that we can run on as
> many devices as possible in various different scenarios. As has been
> aired many times during the late "decadence" discussion on PGO.
>
> Xesam links:
> Ontology: http://xesam.org/main/XesamOntology
> Homepage: http://xesam.org

I hope you where serious about your request for feedback, because here
is some more :-)

DBus?
I believe that the future of Gnome revolves around standardized dbus
interfaces and well documented data models (and at least a few others
on PGO has expressed the same opinion). Is it not an idea to base
Soylent on this too? In this context the proposed API would be that of
a client lib provided by Soylent. This would at least implicitly
abstract out the database backend.

Async API
When you do IO (like database access or dbus) behind the scenes you
basically must provide an async interface as well as a sync one. I
suggest you model the API after the new GIO model (with Cancellables
and GAsyncReply, look at the (quite good) documentation if you are not
familiar with it).

Cheers,
Mikkel