[Soylent-devel] Comments on API proposal

[treitter-dev netdrain com (Travis Reitter)]

Hi Mikkel,

On Thu, 2008-06-19 at 09:54 +0200, Mikkel Kamstrup Erlandsen wrote:
> 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?

Sorry, the document tries to be very broad with that section. The local
database we'll be using *is* e-d-s. We'll clear that up in the next
version of the draft.

My general philosophy for this library is to be as direct as possible
(eg, writing it in the assumption that libebook is a permanent
dependency). We certainly could abstract away the specific vCard
library, database, etc., but I think that could make the codebase and
API harder to work with. If it turns out that it would be worth those
costs, we could abstract them away in version 2.x (which hopefully
wouldn't be necessary for a very long time).

> === 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.

Do you mean like having something like a "GeoStruct" member of the vCard
and then have it have members "GeoN" and "GeoE"?

Are you sure vCard directly supports geo-tagging individual attributes?
As far as I can tell, GEO is its own attribute and refers to the
location of the person themselves.

Of course we could add arbitrary parameters to attributes, but I don't
think we had that in mind for now (geo-tagging could be really
interesting, but it's not my highest priority).

> 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.

We'll check it out. But a bit of libsoylent is practically already
written within the Soylent codebase, and this is Sven's Summer of Code
project, so we've started implementation and probably wouldn't be able
to switch to an abstract back-end and finish the mostly-done/working
prototype in time.

> Person.get_photo() - should this not return a GFile* instead?

Good idea!

> === 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.

Right - gconf is probably not ideal for storing groups (even if we're
just storing their UIDs).

e-d-s handles groups of some sort - we'll have to do a little more
examination here.

> == 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.

I think we have a fair amount of "future proofing" by using e-d-s as our
back-end. As far as I'm aware, it's already pre-installed on most
(possibly all) Gnome Mobile platforms, and basing libsoylent on e-d-s
makes us compatible with some very common applications (evolution and
the members of the Pimlico collection).

Xesam looks interesting, but I'm not sure we need that much complexity
in libsoylent. I think if an application wanted powerful searching they
could use Xesam's access to e-d-s to find matching UIDs, and plug those
into libsoylent functions to get the full people objects.

Thanks for your feedback!

-Travis

> Xesam links:
> Ontology: http://xesam.org/main/XesamOntology
> Homepage: http://xesam.org
> 
> Cheers,
> Mikkel
> _______________________________________________
> Soylent-devel mailing list
> Soylent-devel at lists.codethink.co.uk
> http://lists.codethink.co.uk/cgi-bin/mailman/listinfo/soylent-devel
>