[sugar] Proper D-Bus usage (was Re: October 29 - Tarballs due for 0.83.1)

[Tomeu Vizoso]

On Wed, Oct 29, 2008 at 5:30 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 29.10.2008, at 03:42, Marco Pesenti Gritti wrote:
>
>> On Wed, Oct 29, 2008 at 9:45 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net>
>> wrote:
>>>
>>> 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.
>
> I don't see how it would be "inconsistent" that when an activity saves a
> "title" meta-data property which obviously is a string, and it resumes, to
> expect it will be returned as a string and not magically converted to a byte
> array. An activity should not have to care about the DS's internal
> representation.

I don't see what stops an activity from storing a sequence of bytes
that doesn't conform to any text encoding. The DS won't be able to
index it, but should it reject the entry?

How is the DS expected to return this sequence as a D-Bus string? What
will happen to eToys or other activities that expect all titles come
from the DS as UTF-8 strings?

> For custom properties you could state they must be byte arrays, but for the
> known properties it certainly is more appropriate to use the actual data
> type.

What's the "actual data type"? The type that the activity provided
when the property was first sent to the DS? Or the convention we used
in the older DS?

> A byte array is not a string. Or vice versa. If you disagree, ask the
> D-Bus designers why they did put in a string type instead of simply using
> byte arrays.

This is a matter of naming. In some environments, a string is plainly
a sequence of bytes. In some others, strings are sequences of bytes
expected to contain textual data in some specific encoding.

> And after all, the meta data is declared to be a{sv} instead of a{say}
> precisely to accommodate appropriate types for the values.

Can you extend on what you mean by "accommodate appropriate types for
the values"?

>> After all I think the best solution here is to adapt Etoys.
>
> "Best" in what sense? It indeed is easy enough to make Etoys cope with byte
> arrays, but IMHO it adds to the confusion of every future implementer of a
> non-Python activity.

I personally think that saying that all are byte arrays and that
activities are responsible for decoding them is the least confusing
path. The alternative is very error prone and depends on different
activity authors agreeing on the format of the properties they share.
See the DND mess for an example. And see xattrs for a design that
avoids this mess.

>> The inconsistency could be really confusing.
>
>
> I mentioned it before, and I still maintain that this is an abuse of D-Bus.
> Things that are strings should be transmitted as strings. If nothing else it
> makes debugging a lot easier - strings will be rendered as strings by the
> various D-Bus diagnostic tools.

As I explained before, "Things that are strings" means that someone
needs to decide what is a string and what not. And if that someone
aren't the leafs, then others need to be communicated of this decision
and act accordingly. I'm not sure which benefit brings all this
complexity.

> So, pretty please ... with sugar on top ;) deliver the strings as strings.

I personally don't care so much about the D-Bus API being perfect,
because we have already agreed that a POSIX-based API could work even
better.

So if by:

-  stating on the API docs that some fixed set of properties are to be
strings and the others byte sequences,
- and raising an exception when an activity feeds it something that is
not a string

activity authors can be made significantly happy, I can do that.

Regards,

Tomeu