On Wed, Oct 29, 2008 at 9:45 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote: > The D-Bus method signature has always specified that property values > are variants, thus the D-Bus level of the API hasn't changed.
Ah ok, I thought the dbus signature was changed. It also has to be said that the change is transparent to python activities. > As was explained in that email, if we support that activities can > specify new properties (such as "page") I don't think that the DS > should have to make any assumption about the data type of these > properties. If the DS had to, then activities would need to > communicate this data type and cases where one activity adds an > existing property but with a different type should be handled > somewhat. All this seems to introduce great fragility in the DS and > activities and I don't really think it's productive. File systems that > support file attributes have this exact problem and at least xattrs > has chosen the same approach that I propose. Yeah, we discussed that at length and I agree with it. > 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. After all I think the best solution here is to adapt Etoys. The inconsistency could be really confusing. Marco _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
