[sugar] October 29 - Tarballs due for 0.83.1

[Tomeu Vizoso]

On Tue, Oct 28, 2008 at 11:15 PM, Marco Pesenti Gritti
<mpgritti at gmail.com> wrote:
> On Tue, Oct 28, 2008 at 11:04 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> Well, some of the API uses "variable" types, so even if the interface does
>> not change literally, changing the types involved poses a problem.
>>
>> E.g., meta-data properties are declared as dictionary with string keys but
>> arbitrary values ("a{sv}"). In practice, all meta data values are strings.
>
> They are in practice all strings because all the properties defined by
> the datastore are strings, and we didn't persist custom properties
> (and so no one used them)?
>
>> They used to use the String ("s") D-Bus type, but now Tomeu changed it to
>> byte arrays ("ay"). This is breaking Etoys resume which reads the title
>> property and expects a String but gets a ByteArray.
>
> Hm, that sort of sucks. I'd like to hear the rationale of this change
> from Tomeu and why we should break API to do it.

I actually asked for comments in an email last month:
http://lists.laptop.org/pipermail/sugar/2008-September/008601.html

But rereading it now, I can easily understand that Bert didn't noticed
how this change would affect Etoys.

The D-Bus method signature has always specified that property values
are variants, thus the D-Bus level of the API hasn't changed.

As was explained in that email, if we support that activities can
specify new properties (such as "page") I don't think that the DS
should have to make any assumption about the data type of these
properties. If the DS had to, then activities would need to
communicate this data type and cases where one activity adds an
existing property but with a different type should be handled
somewhat. All this seems to introduce great fragility in the DS and
activities and I don't really think it's productive. File systems that
support file attributes have this exact problem and at least xattrs
has chosen the same approach that I propose.

If the DS doesn't know about the properties' types, then it makes
sense to handle them in the simplest data type possible in D-Bus: a
byte array.

Now, what adds quite a bit of confusion to this subject is that what
are called strings in C or Python are just byte arrays, no decoding of
its contents is performed. But in D-Bus, a string must be UTF-8.
Obviously, we couldn't store non-textual data in such strings and we
really don't want to go around encoding stuff to Base64.

> Let's keep in mind that we are probably going to change the datastore
> API again in the near future. Also, the datastore dbus interface is
> currently marked as STABLE, as I pointed out in my API policy email
> (that's pending objections/discussion though).

I have stopped work on the DS and Journal because OLPC is apparently
funding the development of a replacement for them and the Sugar
community has decided (that's my understanding, please correct me if
I'm wrong) to give some time to see if those efforts can produce
something shippable for 0.84.

We could easily hack the DS in 0.83 to return D-Bus strings for
standard properties that are known (or rather, expected) to contain
textual data, but introducing this inconsistency in the API may not be
such a good idea.

Regards,

Tomeu