[Soylent-devel] Comments on API proposal

[mikkel kamstrup gmail com (Mikkel Kamstrup Erlandsen)]

2008/6/19 Travis Reitter <treitter-dev at netdrain.com>:
> 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).

For xesam-glib I've had great use of abstracting out the dbus
interface, in a GInterface. This way I can add test implementations
and plug into my unit tests. This has worked very well. However
abstracting all of libebooks functionality is probably (no, seriously)
overkill. So it depends on what your needs are.

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

I think I somehow picked up some wrong info on vcard, and I believe
you are right. A note on geotagging - I know first hand that makers of
mobile devices are very interested in this (you can probably guess who
:-D).

Cheers,
Mikkel