Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys
On Thu, 2010-07-29 at 00:23 -0400, C. Scott Ananian wrote: On Wed, Jul 28, 2010 at 12:06 PM, Bernie Innocenti ber...@codewiz.org wrote: There's no reason to have both a filename and a dbus-like name for the same thing. The former must already be unique on both distribution sites and in the Activities directory. I claim we should be using the dbus-like name for both distribution sites and in the Activities directory. Then activity bundle files should be named like so? org.laptop.Browse-42.xo org.sugarlabs.Browse-666.xo And their installed counterparts would look like these, correct? ~/Activities/org.laptop.Browse.activity ~/Activities/org.sugarlabs.Browse.activity No version number, since we don't seem to allow parallel installation of multiple instances of the very same activity, right? If a developer takes over development of, say, org.laptop.Measure, should the developer rename the bundle to org.codewiz.Measure or leave it alone? In case of a rename, how do they ensure a smooth upgrade path? Sorry to ask so many questions, but global uniqueness is a worthwhile feature to have only if with well-defined semantics and a clear purpose. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys
On 27 July 2010 23:57, Bernie Innocenti ber...@codewiz.org wrote: On Tue, 2010-07-27 at 18:21 -0400, C. Scott Ananian wrote: This is a nicely decentralized mechanism for choosing identifiers which are guaranteed by construction never to conflict. It is indeed a simple and nice scheme, but why is such uniqueness a desiderable feature when developers can--and in fact *do*--often distribute forks of existing activities? Lucian has just created a fork of Browse and ParaguayEduca has a fork of XoIRC and VncLauncher on its wiki. In all cases, the bundle_id was intentionally left unmodified to ensure upgrades would work. Actually, after careful consideration I've rebranded Browse-webkit to Surf. (if the bundle_id were instead changed, funny things would happen when a user tries to install both bundles on the same machine). If sugarlabs is willing to maintain a mechanism for ensuring uniqueness, feel free to prepend org.sugarlabs to whatever activities you have registered. A good surrogate could be that no two activities with the same name can be uploaded to ASLO. Without a fancy scheme for signed bundles, nothing forbids people from distributing bundles with conflicting names from other sites, regardless of what uniqueness scheme gets chosen. For all other purposes, the bundle_id is just a string which could contain anything. The bundle_id org.tuxpaint.sugar-is-lame worked flawlessly for all this time. Yes, this identifier is childish, but conforms precisely to the rules outlined above, which ensure its uniqueness. It's not actually conforming, it has hyphens! ;-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys
On 27.07.2010, at 18:57, Bernie Innocenti wrote: On Tue, 2010-07-27 at 18:21 -0400, C. Scott Ananian wrote: This is a nicely decentralized mechanism for choosing identifiers which are guaranteed by construction never to conflict. It is indeed a simple and nice scheme, but why is such uniqueness a desiderable feature I thought because the laptops are connected, and this scheme ensures that a local and a remote activity use the same id. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys
On Tue, 2010-07-27 at 19:57 -0400, C. Scott Ananian wrote: A good surrogate could be that no two activities with the same name can be uploaded to ASLO. Translated name? English name? No Spanish name may conflict with a Portuguese or English name? Seems a bit strange to me. Filesystem name. Which is often the same of the English name, but not always (Oficina - Paint). There's no reason to have both a filename and a dbus-like name for the same thing. The former must already be unique on both distribution sites and in the Activities directory. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys
On Wed, Jul 28, 2010 at 12:06 PM, Bernie Innocenti ber...@codewiz.org wrote: There's no reason to have both a filename and a dbus-like name for the same thing. The former must already be unique on both distribution sites and in the Activities directory. I claim we should be using the dbus-like name for both distribution sites and in the Activities directory. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys
On Tue, Jul 27, 2010 at 5:14 PM, Bernie Innocenti ber...@codewiz.org wrote: The bundle base name (e.g Record) should be unique by itself, because you can't have two directories named Record.activity in your activities directory. This is, IMO, a bug. The directory should really be named after the bundle id. The bundle ID is not a dbus name, it just conforms to the character rules for dbus names. To quote http://wiki.laptop.org/go/Activity_bundles : -- begin quote -- This is the activity bundle identifier. It is required. The name should conform to the D-Bus spec - in particular, hyphens are not allowed (although this wasn't enforced in earlier builds, see Trac 6226). It is recommended that Java package naming conventions are used when chosing bundle identifiers, to ensure uniqueness. Briefly, your name should begin with the reversed domain name of an organization you belong to. The reversed domain name part is supposed to be rooted in some actual DNS-rooted namespace. You don't need to own this domain; you just need to have a reasonable claim on some unique name at that domain. There are several ways to derive one: If your email address is yourn...@somemailhost.com, then you could use com.somemailhost.yourname.YourActivity. You could set up a web page on a free hosting service with information about your activity, and use a name derived from its URL. For example, if you create a page at http://www.geocities.com/xotumusica for your activity, then com.geocities.www.xotumusica is a reasonable bundle_id. If nothing else is available, even org.laptop.wiki.YourActivityPageTitle is probably a reasonable bundle_id, provided that you create the YourActivityPageTitle page. Remember, bundle_ids should be unique, so you should double check that the YourActivityPageTitle page doesn't already exist (and then create it) before using this as your bundle_id. end quote This is a nicely decentralized mechanism for choosing identifiers which are guaranteed by construction never to conflict. Even if it were possible to install org.sugarlabs.Record and com.microsoft.Record in parallel, having two different activities with the same name would be confusing and almost never what the user expected. You're neglecting localization issues here. Perhaps there's still something we could do to simplify the design without breaking backwards compatibility: if an activity doesn't specify a bundle_id, its dbus name could be derived from the bundle name by pre-pending org.sugarlabs. (or org.laptop., it doesn't matter) to it. If sugarlabs is willing to maintain a mechanism for ensuring uniqueness, feel free to prepend org.sugarlabs to whatever activities you have registered. For all other purposes, the bundle_id is just a string which could contain anything. The bundle_id org.tuxpaint.sugar-is-lame worked flawlessly for all this time. Yes, this identifier is childish, but conforms precisely to the rules outlined above, which ensure its uniqueness. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys
On Tue, 2010-07-27 at 18:21 -0400, C. Scott Ananian wrote: This is a nicely decentralized mechanism for choosing identifiers which are guaranteed by construction never to conflict. It is indeed a simple and nice scheme, but why is such uniqueness a desiderable feature when developers can--and in fact *do*--often distribute forks of existing activities? Lucian has just created a fork of Browse and ParaguayEduca has a fork of XoIRC and VncLauncher on its wiki. In all cases, the bundle_id was intentionally left unmodified to ensure upgrades would work. (if the bundle_id were instead changed, funny things would happen when a user tries to install both bundles on the same machine). If sugarlabs is willing to maintain a mechanism for ensuring uniqueness, feel free to prepend org.sugarlabs to whatever activities you have registered. A good surrogate could be that no two activities with the same name can be uploaded to ASLO. Without a fancy scheme for signed bundles, nothing forbids people from distributing bundles with conflicting names from other sites, regardless of what uniqueness scheme gets chosen. For all other purposes, the bundle_id is just a string which could contain anything. The bundle_id org.tuxpaint.sugar-is-lame worked flawlessly for all this time. Yes, this identifier is childish, but conforms precisely to the rules outlined above, which ensure its uniqueness. It's not actually conforming, it has hyphens! ;-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys
On Tue, Jul 27, 2010 at 6:57 PM, Bernie Innocenti ber...@codewiz.org wrote: On Tue, 2010-07-27 at 18:21 -0400, C. Scott Ananian wrote: This is a nicely decentralized mechanism for choosing identifiers which are guaranteed by construction never to conflict. It is indeed a simple and nice scheme, but why is such uniqueness a desiderable feature when developers can--and in fact *do*--often distribute forks of existing activities? I think this is an orthogonal problem. I'm sure that some disagree. (if the bundle_id were instead changed, funny things would happen when a user tries to install both bundles on the same machine). Bug. If sugarlabs is willing to maintain a mechanism for ensuring uniqueness, feel free to prepend org.sugarlabs to whatever activities you have registered. A good surrogate could be that no two activities with the same name can be uploaded to ASLO. Translated name? English name? No Spanish name may conflict with a Portuguese or English name? Seems a bit strange to me. For all other purposes, the bundle_id is just a string which could contain anything. The bundle_id org.tuxpaint.sugar-is-lame worked flawlessly for all this time. Yes, this identifier is childish, but conforms precisely to the rules outlined above, which ensure its uniqueness. It's not actually conforming, it has hyphens! ;-) Oh, that's right, I *did* have a legit reason to dislike the name! ;-) --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Changing bundle_id and version scheme for Etoys
On 22.07.2010, at 12:18, Lucian Branescu wrote: I was thinking of changing the bundle_id of Browse-webkit from 'org.laptop.WebActivity' to 'org.sugarlabs.WebActivity', to allow both Browse to be installed and working at the same time. However, this might confuse users yet again, since they'd have their good old Browse along with a possibly broken one. I have a similar problem. The bundle_id for Etoys is org.vpri.Etoys because the activity was initially developed at VPRI. Now that VPRI is not involved anymore we should change it to e.g. org.squeak.Etoys to reflect the new organization. Also, for some time I wanted to change the versioning scheme. I used to increment the version number and release a new activity bundle whenever something in the base system's etoys changed, even if there was no change to the activity itself (the bundle is just a thin wrapper). That doesn't really make sense. I was hoping Sugar's new dotted-version scheme would arrive in time for this, but has it? But what about existing Journal entries? They would still be tagged with the old bundle id, though the mime type would identify them as Etoys projects. If the old activity was uninstalled, would the new one automatically open those entries? - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys
On Thu, Jul 22, 2010 at 12:49 PM, Bert Freudenberg b...@freudenbergs.de wrote: On 22.07.2010, at 12:18, Lucian Branescu wrote: I was thinking of changing the bundle_id of Browse-webkit from 'org.laptop.WebActivity' to 'org.sugarlabs.WebActivity', to allow both Browse to be installed and working at the same time. However, this might confuse users yet again, since they'd have their good old Browse along with a possibly broken one. I have a similar problem. The bundle_id for Etoys is org.vpri.Etoys because the activity was initially developed at VPRI. Now that VPRI is not involved anymore we should change it to e.g. org.squeak.Etoys to reflect the new organization. Also, for some time I wanted to change the versioning scheme. I used to increment the version number and release a new activity bundle whenever something in the base system's etoys changed, even if there was no change to the activity itself (the bundle is just a thin wrapper). That doesn't really make sense. I was hoping Sugar's new dotted-version scheme would arrive in time for this, but has it? But what about existing Journal entries? They would still be tagged with the old bundle id, though the mime type would identify them as Etoys projects. If the old activity was uninstalled, would the new one automatically open those entries?'' I don't know of a solution to this problem except that mimetypes will mitigate some of the problem. Updating is another problem... AFAIK, the updater uses the bundle_id. -walter - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Changing bundle_id and version scheme for Etoys
On 22 July 2010 17:49, Bert Freudenberg b...@freudenbergs.de wrote: On 22.07.2010, at 12:18, Lucian Branescu wrote: I was thinking of changing the bundle_id of Browse-webkit from 'org.laptop.WebActivity' to 'org.sugarlabs.WebActivity', to allow both Browse to be installed and working at the same time. However, this might confuse users yet again, since they'd have their good old Browse along with a possibly broken one. I have a similar problem. The bundle_id for Etoys is org.vpri.Etoys because the activity was initially developed at VPRI. Now that VPRI is not involved anymore we should change it to e.g. org.squeak.Etoys to reflect the new organization. If it doesn't bother you that vpri is in the bundle name and VPRI themselves don't have a problem with it, I don't think you should bother changing it. For example many activities are org.laptop.*, even though they're now developed under Sugar Labs. Also, for some time I wanted to change the versioning scheme. I used to increment the version number and release a new activity bundle whenever something in the base system's etoys changed, even if there was no change to the activity itself (the bundle is just a thin wrapper). That doesn't really make sense. I was hoping Sugar's new dotted-version scheme would arrive in time for this, but has it? Then you could just not bump the activity version if it doesn't change. Don't know about dotted versions. But what about existing Journal entries? They would still be tagged with the old bundle id, though the mime type would identify them as Etoys projects. If the old activity was uninstalled, would the new one automatically open those entries? Yes, it would open those entries if the mime types are correct. But the updater would probably not update etoys if it had a different bundle_id. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
