[sugar] Proper D-Bus usage

[Bert Freudenberg]

On 31.10.2008, at 03:30, Tomeu Vizoso wrote:

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

We are talking only about the mandatory, well-defined meta data  
properties. If an activity stores an invalid string, it is buggy, and  
bad things are expected to happen.

> What
> will happen to eToys or other activities that expect all titles come
> from the DS as UTF-8 strings?

The activities will break with badly encoded byte arrays too, because  
they will try to decode it as if it was a UTF-8 string.

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

No, the type defined by the contract between Sugar and its Activities.  
This is something like "the 'title' property is a utf-8 encoded string  
specifying the main title to be displayed in the journal list". Am I  
the only one who would find mentioning of byte arrays in that spec  
ugly and unnecessary?

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

Oh please, it is not just a matter of naming. Think, for example,  
about how you would compare two strings, and how you would compare two  
byte arrays. Or how you would present a string to a user (developer)  
vs. a byte array.

Besides, we use high-level representations to aid reasoning about  
what's going on inside the computer. By dumbing down everything to the  
lowest possible representation you are removing valuable semantics.

I can't believe I am really the only one on this list who thinks that  
Sugar should be explorable all the way down. If we collectively  
thought that byte arrays are as fine as higher-level constructs, why  
would we even be here?

>> 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"?

To use the string type for properties that are text strings, to use  
the integer type for properties that are numbers, to use the boolean  
type for properties that are truth values, etc.

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

I think you are only seeing the complexity it would add to your  
datastore implementation, where I only see the conceptual simplicity.

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


Don't bother, unless someone else supports my ramblings.

Most activity authors wouldn't notice anyway because they do not use  
the datastore directly. I made Etoys deal with the byte arrays. I'm  
not sure there even is another non-Python activity that interfaces to  
the datastore.

And others do not seem to use the D-Bus interface interactively. I  
learned about how the datastore works by firing up a Python shell and  
introspecting its D-Bus service (this was before Squeak had a nice D- 
Bus inspector). If all values had been byte arrays that would have  
made this significantly less pleasant. It makes looking under the hood  
harder.

- Bert -