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