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

2008-10-31 Thread Tomeu Vizoso
On Wed, Oct 29, 2008 at 5:30 PM, Bert Freudenberg [EMAIL PROTECTED] wrote:
 On 29.10.2008, at 03:42, Marco Pesenti Gritti wrote:

 On Wed, Oct 29, 2008 at 9:45 AM, Tomeu Vizoso [EMAIL PROTECTED]
 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
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


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

2008-10-31 Thread Benjamin M. Schwartz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tomeu Vizoso wrote:
 And see xattrs for a design that
 avoids this mess.

xattr values are also just bytes with no type, and so will have exactly
the same problem.  Their behavior would be equivalent to D-Bus's a{ayay}.

Python's behavior in this domain is also in flux.  Python 3.0 will have
separate types for unicode strings and unencoded bytestrings.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkLC60ACgkQUJT6e6HFtqSgwACdERgkXfq2kFuDiYufYdoQLCaP
rI8AmQGEQCDTop7U0D6bJHAoE66DA/xz
=1slO
-END PGP SIGNATURE-
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


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

2008-10-31 Thread Tomeu Vizoso
On Fri, Oct 31, 2008 at 2:44 PM, Benjamin M. Schwartz
[EMAIL PROTECTED] wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Tomeu Vizoso wrote:
 And see xattrs for a design that
 avoids this mess.

 xattr values are also just bytes with no type, and so will have exactly
 the same problem.  Their behavior would be equivalent to D-Bus's a{ayay}.

The mess I was referring to was the situation around the clipboard in
linux desktops, where apps have trouble sharing data because specs are
badly implemented or there are no spec for some data types.

 Python's behavior in this domain is also in flux.  Python 3.0 will have
 separate types for unicode strings and unencoded bytestrings.

Sounds pretty good.

Regards,

Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


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

2008-10-29 Thread Bert Freudenberg
On 29.10.2008, at 03:42, Marco Pesenti Gritti wrote:

 On Wed, Oct 29, 2008 at 9:45 AM, Tomeu Vizoso  
 [EMAIL PROTECTED] 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.

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

And after all, the meta data is declared to be a{sv} instead of a{say}  
precisely to 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.

 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.

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

- Bert -


___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


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

2008-10-29 Thread Marco Pesenti Gritti
On Wed, Oct 29, 2008 at 5:30 PM, Bert Freudenberg [EMAIL PROTECTED] wrote:
 On 29.10.2008, at 03:42, Marco Pesenti Gritti wrote:
 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 think Tomeu point is that the DS should know nothing about the type
of the metadata properties and interpretation of the data blob (the
array of bytes) should be left entirely to the activities.

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

Yeah but the interface was written for a datastore which had a notion
of metadata property type (although a very bad one). The new one does
not.

Marco
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


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

2008-10-29 Thread Bert Freudenberg
On 29.10.2008, at 09:57, Marco Pesenti Gritti wrote:

 On Wed, Oct 29, 2008 at 5:30 PM, Bert Freudenberg [EMAIL PROTECTED] 
  wrote:
 On 29.10.2008, at 03:42, Marco Pesenti Gritti wrote:
 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 think Tomeu point is that the DS should know nothing about the type
 of the metadata properties and interpretation of the data blob (the
 array of bytes) should be left entirely to the activities.

It's not a data blob. The mandatory meta-data properties are well  
defined. This is (or should be) part of the Sugar specification. Like,  
the Journal has to agree with activities that the meta data property  
named title is actually a Unicode string. It is *not* left to the  
activities.

Besides, if you throw away the knowledge that something is a string,  
then you lose quite a bit of useful information. Like, full text  
search pretty much requires knowing what is a string and what not. You  
may want to read about comparing Unicode strings - it certainly is not  
as simple as comparing byte arrays. Let alone if we want to do fuzzy  
search.

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

 Yeah but the interface was written for a datastore which had a notion
 of metadata property type (although a very bad one). The new one does
 not.


Then change the API signature and do not pretend it did not break.

Any comment on the debugability concerns?

- Bert -

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar


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

2008-10-29 Thread Marco Pesenti Gritti
On Wed, Oct 29, 2008 at 6:32 PM, Bert Freudenberg [EMAIL PROTECTED] wrote:
 It's not a data blob.

It *is* a blob in Tomeu design, which I'll let him defend.

 Yeah but the interface was written for a datastore which had a notion
 of metadata property type (although a very bad one). The new one does
 not.


 Then change the API signature and do not pretend it did not break.

If it doesn't cause more issues than leaving it as is, I'd agree with that.

Marco
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar