Re: [sugar] Proper D-Bus usage (was Re: October 29 - Tarballs due for 0.83.1)
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)
-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)
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)
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)
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)
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)
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
