[Soylent-devel] Comments on API proposal

[mikkel kamstrup gmail com (Mikkel Kamstrup Erlandsen)]

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

Cheers,
Mikkel