Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 09:00:49AM +, Aleksey Lim wrote: > On Tue, Jul 28, 2009 at 01:49:15PM +0545, Daniel Drake wrote: > > 2009/7/28 Aleksey Lim : > > > Proposal is not about storing all versions but about possibility of > > > storing not only one(last?) version and we can uninstall old versions > > > by removing entries from journal. > > > > The journal can't delete activities that are installed by a package at > > /usr/share/activities, and I also think it is unlikely that our users > > would realise to do this even if it were possible. > > > > > There is no confusion, sugar is aware of what versions of particular > > > activity it has by using datastore.find() method, so user can run > > > `rpm update`, install any version by downloading .xo and sugar will run > > > last version(when user create new activity instance) or run particular > > > version(if activity object requires it). > > > > I was referring to confusion by deployments and those who are > > diagnosing bugs and soforth. > > > > > btw, activity can declare, in activity instance object, what activity > > > version(range) should be used with this particular instance object. > > > > Sounds like overcomplication. > > > > > > In response to your question on how I think it should be done, I feel > > that it's time to admit that packaging activities in this way is a > > mess. We should leave packaging and the related complications to the > > experts - packagers, and the package manager, and then we can stop > > wasting our time on it. For some kind of cross-distro package manager > > compatibility, someone recently raised the idea of PackageKit which > > seems well worth investigating and given its rapid development can > > probably be adapted to our needs. > > > > IOW I feel that the concept of sugar providing prepackaged binary > > activities should die. > > +1, the way which was chosen by soas is a good example(all activities > come from .xo bundles) > > > I think you would be a good person to work on > > this, and it is an interesting problem. > > > > > Well we can't say to activity developers that they must write > > > backwards-incompatible activities otherwise we won't host them on ASLO. > > > In that case using compatibility ranges of versions could fix problem > > > (w/o obliging developers write complicated code for > > > merge/support-backwards-incompatibility). > > > > It's nice to have the freedom to post whatever I want on ASLO and I'm > > not saying that should change. I'm free to write a buggy activity or > > one that isn't sugarized and post it on ASLO. Even though my activity > > is low quality and doesn't fit into the desktop, I'm welcome to post > > it. The consequence is that my activity probably won't be included in > > deployments, and I'll get some mails from testers making suggestions > > how I could improve it, and maybe even some patches. I'd say that this > > case is no different. > > > > > I like this idea only if all sugar users have 100% access to internet. > > > And they can run "upgrade my 0.82 to 0.84 from internet" process by one > > > click. But imho thats impossible in case of educational infrastructure > > > around of the world. > > > > The responsibility of keeping all machines in sync can be handled by > > the deployments, with the aid of good tools from Sugar/distro/OLPC. > > This is how it already works in the field. It's not your problem, but > > you could certainly help improve those tools and their concepts which > > seem a bit neglected right now. > > Well, for me "0.82 doesn't work with 0.84" is very strong requirement > btw it relates to [2] > > > > imho activities are the same kind of objects - user should have chance > > > to edit/hack/share them like other sugar objects. > > > > Good point, but this seems to be beyond what sugar is capable of at > > the moment and raises more questions. Perhaps once there is the > > ability to modify your activity within sugar, the development activity > > could offer functionality to package up the modified version and save > > it in the journal. Exactly how the user could modify activities, how > > the user-modified activity would be saved on-disk alongside the > > original one, how they would be differentiated in the UI and how the > > user could switch between the two seems to be out of scope of this > > discussion -- or at least I can't see how it would be covered by your > > proposal. > > Yeah it raise many new questions. > > In my mind we can do the first step on this road by creating > activity-less Composite Journal entries[2](objects w/o activity DS > field), so over activities(like Develop) can change activity's code > inplace. And delegate(for the first time at least) all maintenance > procedures (like what version I can change, what version is my backup > copy) to users, they can do this if all activities will be Journal > entries. > > [1] http://wiki.sugarlabs.org/go/Features/Decoupling_of_Sucrose > [2] http://wiki.sugarlabs
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 04:19:15PM -0700, Edward Cherlin wrote: > Sugar on a Stick currently [has Fructose Activities installed] from > packages This has changed now in SoaS and F11-on-XO, which both now just use .xos for Fructose and other non-Glucose activities. Martin pgphc53u8MLGc.pgp Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
On Mon, Jul 27, 2009 at 11:39 PM, Daniel Drake wrote: > 2009/7/28 Aleksey Lim : >> The problems that 0.84 has in case of activity versions are: >> >> * it can't upgrade activities if they were pre-installed from >> native packages; it makes process of upgrading activities >> from .xo impossible > > In reality Sugar's message is confusing here and I don't think any > distributor will mix-and-match the two ways of installing activities. > (either they'll use distro packages and disable .xo, or they will > exclusively use .xo e.g. OLPC). Sugar on a Stick currently presents this problem, where stock Activities are installed from packages, but I can use .xos for anything else. I found that I could go to the Activities directory, delete a preinstalled Activity directory, and install a later version by downloading. I wrote this up on [[The undiscoverable]]. > Daniel > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Silent Thunder (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://earthtreasury.org/worknet (Edward Mokurai Cherlin) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 1:39 AM, Daniel Drake wrote: > 2009/7/28 Aleksey Lim : >> The problems that 0.84 has in case of activity versions are: >> >> * it can't upgrade activities if they were pre-installed from >> native packages; it makes process of upgrading activities >> from .xo impossible > > In reality Sugar's message is confusing here and I don't think any > distributor will mix-and-match the two ways of installing activities. > (either they'll use distro packages and disable .xo, or they will > exclusively use .xo e.g. OLPC). This grows into a somewhat complicated issue for mozilla addons. It is rather common for distributions to mix and match the method for installing addon. Distros tend to repackage addons when they want to add branding or add a bug fix. david > This is a larger problem and I don't think yours is a solution, since > it will result in wasted disk space and we still end up with the > confusion of how activities can be installed and which one is being > used. > >> * sugar can have only one activity version installed at the same >> time i.e. it could be useful to have several versions >> simultaneously e.g. to start proper version when join request >> arrived(activity version of arrived request could be different >> to installed version) > > I think this calls for wider discussion. Having multiple versions of > the same activity installed sounds silly. Instead, activity designers > should be encouraged to strongly avoid making backwards-incompatible > protocol changes, just like the principles of any other software > designer. Once everything is compatible, this problem goes away. Sugar > should continue to make no promises about interoperability between > different major releases (e.g. no promises about 0.82 talking to 0.84) > and hence if it is necessary, activity developers are allowed to break > compatibility once every 6 months, which should be more than enough. > > Finally, I personally don't like the idea of having activities (as in > applications) in the journal. The journal is for recording what the > user has done. > > Daniel > ___ > 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
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 01:01:32PM +0200, Sascha Silbe wrote: > On Tue, Jul 28, 2009 at 10:37:18AM +, Aleksey Lim wrote: > > >Since [3] is(in addition) an idea of having "composite" Journal > >objects(when we have content of bundle stored somewhere in form of > >ready to use directly, and this content is represented by one Journal > >item) we can treat activities like a composite objects. > > > >So, the idea is having Journal entries that should represent > >activities > >(they are regular Journal entries and users can search/tag/etc. them) > >and each of these Journal entries has "entry" field which points to > >directory with activity. Shell can find() DS to be aware of what > >versions/activities it has to start proper > >activity/activity-version to > >activate particular object in Journal. > So [3] is intended to be used inside Sugar itself? I don't think I > like that. :-P > What's the reason for > a) storing several, different entities in the datastore object? The original purpose was fixing ugly(imho) situation with library bundles, we had .xol in Journal, unzipped library in ~/Library, library sidebar in Browse to open libraries. [3] simplifies process, so we have only Journal entry which represent library (we can utilize regular(not yet implemented) Journal features like [4] and [5] to browse and open these libraries). > b) storing actual content outside of the datastore? In fact it was temporary decision(but it works fine w/o dirty hacks) later we can move it to DS(we can get feedback in 0.86 cycle and maybe even change/remove OB at all). [3] http://wiki.sugarlabs.org/go/Features/Object_Bundles [4] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#What.2FAnything_palette [5] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tags_palette -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
Daniel Drake writes: > Finally, I personally don't like the idea of having activities > (as in applications) in the journal. The journal is for > recording what the user has done. I think that **uninstalled** activities belong in the journal. An activity can be in the journal like any random data file, or it can be in the launcher. It can be moved back and forth. This should reduce confusion, clutter, accidental damage, etc. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 13:36, Sascha Silbe wrote: > On Tue, Jul 28, 2009 at 12:59:43PM +0200, Tomeu Vizoso wrote: > >>> The more important point is that it also works for people installing >>> Sugar >>> from packages on their own system, without manual symlink fiddling. My >>> imagined use case is someone doing a "full" Sugar desktop installation >>> (by >>> using a corresponding meta package) and wanting to try out the latest >>> Read >>> release now featuring continuous scrolling (entirely fictional). >> >> Why this person doesn't have Read installed in ~/Activities? > > Because package managers usually don't touch home directories (for good > reasons)? But apps do on their first start. Anyway, this is a packaging issue, representing out-of-DS dirs in the journal doesn't seem to me like directly attacking the problem. Other desktops use PackageKit for this, but we are not going to be able to all interesting activities packaged for all distros anyway. Regards, Tomeu > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKbuKdAAoJELpz82VMF3DaB30H/19vNqdbF0BHfp1DUdHOduzl > Z9plPyqODs5PtE3/Zw/LKH8Ay8wuNHTNOBnM/a01U/1H/19nmkH1IYMv09F+orO9 > vsPhu5o3OCQtMrpI65+7YB3yATGH+W0xgTN7Cx6sNBRt9rfStRrfR7QtXUe5cibq > BpxHaQYI9vyH/OaZxUawykyPj3eEk7iarDNi2y+JnT22/rWZeunQNzj3c8WolpSB > Lc0Qr6A5tYhFUQ6BDrdG/hptMS2Y4+Guu2a0emcjdp5hs59gaw4kfDOQFL/ptyiz > +ZbPUwubCMOd3pFyvMUw3Pu85RxJDpPHdi8d3CcIUg4M2aOcItgsdzCDO22SYJ4= > =1OLo > -END PGP SIGNATURE- > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 12:59:43PM +0200, Tomeu Vizoso wrote: The more important point is that it also works for people installing Sugar from packages on their own system, without manual symlink fiddling. My imagined use case is someone doing a "full" Sugar desktop installation (by using a corresponding meta package) and wanting to try out the latest Read release now featuring continuous scrolling (entirely fictional). Why this person doesn't have Read installed in ~/Activities? Because package managers usually don't touch home directories (for good reasons)? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 10:37:18AM +, Aleksey Lim wrote: Since [3] is(in addition) an idea of having "composite" Journal objects(when we have content of bundle stored somewhere in form of ready to use directly, and this content is represented by one Journal item) we can treat activities like a composite objects. So, the idea is having Journal entries that should represent activities (they are regular Journal entries and users can search/tag/etc. them) and each of these Journal entries has "entry" field which points to directory with activity. Shell can find() DS to be aware of what versions/activities it has to start proper activity/activity-version to activate particular object in Journal. So [3] is intended to be used inside Sugar itself? I don't think I like that. :-P What's the reason for a) storing several, different entities in the datastore object? b) storing actual content outside of the datastore? [3] http://wiki.sugarlabs.org/go/Features/Object_Bundles CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 12:55, Sascha Silbe wrote: > On Tue, Jul 28, 2009 at 12:38:32PM +0200, Tomeu Vizoso wrote: > To avoid space duplication in LTSP environments, ~/Activities can contain symlinks to somewhere in /usr if the deployer wants users to be able to uninstall and upgrade activities. >>> >>> But this won't allow them to downgrade to the system-installed version >>> without using Terminal and fiddling with symlinks. >> >> Anybody thinks this is worth changing so much code thus introducing new >> bugs? > > The more important point is that it also works for people installing Sugar > from packages on their own system, without manual symlink fiddling. My > imagined use case is someone doing a "full" Sugar desktop installation (by > using a corresponding meta package) and wanting to try out the latest Read > release now featuring continuous scrolling (entirely fictional). Why this person doesn't have Read installed in ~/Activities? Regards, Tomeu > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKbtkHAAoJELpz82VMF3Da4yIH/Aw/GR+wWR1bg0e6mDt/K0xt > fDDayc8V4/T7zA9EuJti9Hfykh41s2W+1UyzMNMMCAdZHY5HbMa2kAmI32tf7JCA > /bKVf5y4Df2YNFg6PKc7Sq0hrzLHMsZQJqua803OKA2+MhnlyhLG5wSe1FrWU4NU > BQ3/W6iI1cHFf5UkoJNmWiiDePMDxH3M7eh7h9wMhrvN7TJud0jZndyuNyjIZTm0 > +En0smg3NHAlWJg2shFfHM5xAvCOq3cZg1zCFmJWiZmIGrrQI8rFi0zjgiw9bPfb > yBKkTQpTdBCvNsNomVCcwSNwDvsHAu+N/mamXNa9tDxdKusJcVe+YzfBGX6rfSc= > =gtAA > -END PGP SIGNATURE- > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 12:38:32PM +0200, Tomeu Vizoso wrote: To avoid space duplication in LTSP environments, ~/Activities can contain symlinks to somewhere in /usr if the deployer wants users to be able to uninstall and upgrade activities. But this won't allow them to downgrade to the system-installed version without using Terminal and fiddling with symlinks. Anybody thinks this is worth changing so much code thus introducing new bugs? The more important point is that it also works for people installing Sugar from packages on their own system, without manual symlink fiddling. My imagined use case is someone doing a "full" Sugar desktop installation (by using a corresponding meta package) and wanting to try out the latest Read release now featuring continuous scrolling (entirely fictional). CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 12:30, Sascha Silbe wrote: > On Tue, Jul 28, 2009 at 12:18:58PM +0200, Tomeu Vizoso wrote: > >> To avoid space duplication in LTSP environments, ~/Activities can >> contain symlinks to somewhere in /usr if the deployer wants users to >> be able to uninstall and upgrade activities. > > But this won't allow them to downgrade to the system-installed version > without using Terminal and fiddling with symlinks. Anybody thinks this is worth changing so much code thus introducing new bugs? Regards, Tomeu > PS: Please don't CC me, I'm subscribed to the list and set Mail-Followup-To > accordingly (GMail ignores this unfortunately). By CCing my Reply-To address > you cause my MUA to use that address as From when replying, so I have to > manually change the address because otherwise the mailing list won't accept > my post (i.e. queue it for moderation). > > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKbtNVAAoJELpz82VMF3Da1xkH/joZkWzhgymva5YzNPnDF1gG > SH0o82IDpc57XMV9ltRzDwa5sT9WlfjPJcz45LGg/sAhFBHO8ySreh83+iwSSpu4 > dM//r59twdlruVOwBEQ5OJsv95CXkFEOitjwzRGot6SHAmkQaDrR9rUICa5fF1Z2 > wJSRHgb2eSl/tlNnYp4jqkxChmtmpNQWnl6tttYqV4+Rf1A9kBrLuvTGHp5ViEtq > hNUng6ucG3Zfv4umJBeLpJW7Gm9JJbPcnRBW0s/AsQLBDQYSqoIyOCj367ahgpXb > Bt+gym2RYsRBDkLzoshEsfBuvTH2CFOHEZlcDzI7VY8HXJNxRSiPl6v77FB/vjE= > =cSvj > -END PGP SIGNATURE- > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 12:14:54PM +0200, Sascha Silbe wrote: > On Tue, Jul 28, 2009 at 05:14:57AM +, Aleksey Lim wrote: > > >* it can't upgrade activities if they were pre-installed from > > native packages; it makes process of upgrading activities > > from .xo impossible > Yeah, this is really a PITA. > > >* sugar can have only one activity version installed at the same > > time > That's being worked on, see bug #1042 [1] (patch available, but not > merged yet) and #1053 [2] (fixed). > > >i.e. it could be useful to have several versions > > simultaneously e.g. to start proper version when join request > > arrived(activity version of arrived request could be different > > to installed version) > That's not implemented yet, of course, and needs further design > decisions (esp. regarding the UI). > > >[1] http://wiki.sugarlabs.org/go/Features/Activity_Objects > This sounds a lot like what I imagined as a solution for the first > problem: represent system-installed activities as a virtual Journal > object - inside Journal / shell only, not exposed to activities or > the datastore. > What I don't get is how this depends on your Object Bundles proposal > [3]. AIUI the latter is only an on-the-wire format, similar to the > way regular Bundles work now. Since [3] is(in addition) an idea of having "composite" Journal objects(when we have content of bundle stored somewhere in form of ready to use directly, and this content is represented by one Journal item) we can treat activities like a composite objects. So, the idea is having Journal entries that should represent activities (they are regular Journal entries and users can search/tag/etc. them) and each of these Journal entries has "entry" field which points to directory with activity. Shell can find() DS to be aware of what versions/activities it has to start proper activity/activity-version to activate particular object in Journal. > [1] http://dev.sugarlabs.org/ticket/1042 > [2] http://dev.sugarlabs.org/ticket/1053 > [3] http://wiki.sugarlabs.org/go/Features/Object_Bundles > > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 12:18:58PM +0200, Tomeu Vizoso wrote: To avoid space duplication in LTSP environments, ~/Activities can contain symlinks to somewhere in /usr if the deployer wants users to be able to uninstall and upgrade activities. But this won't allow them to downgrade to the system-installed version without using Terminal and fiddling with symlinks. PS: Please don't CC me, I'm subscribed to the list and set Mail-Followup-To accordingly (GMail ignores this unfortunately). By CCing my Reply-To address you cause my MUA to use that address as From when replying, so I have to manually change the address because otherwise the mailing list won't accept my post (i.e. queue it for moderation). CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 12:14, Sascha Silbe wrote: > On Tue, Jul 28, 2009 at 05:14:57AM +, Aleksey Lim wrote: > >> * it can't upgrade activities if they were pre-installed from >> native packages; it makes process of upgrading activities >> from .xo impossible > > Yeah, this is really a PITA. As discussed in #sugar, deployers can choose between putting activities in /usr/share or in ~/Activities depending on whether they want to give users an easy way to uninstall and update activities. To avoid space duplication in LTSP environments, ~/Activities can contain symlinks to somewhere in /usr if the deployer wants users to be able to uninstall and upgrade activities. Regards, Tomeu >> * sugar can have only one activity version installed at the same >> time > > That's being worked on, see bug #1042 [1] (patch available, but not merged > yet) and #1053 [2] (fixed). > >> i.e. it could be useful to have several versions >> simultaneously e.g. to start proper version when join request >> arrived(activity version of arrived request could be different >> to installed version) > > That's not implemented yet, of course, and needs further design decisions > (esp. regarding the UI). > >> [1] http://wiki.sugarlabs.org/go/Features/Activity_Objects > > This sounds a lot like what I imagined as a solution for the first problem: > represent system-installed activities as a virtual Journal object - inside > Journal / shell only, not exposed to activities or the datastore. > What I don't get is how this depends on your Object Bundles proposal [3]. > AIUI the latter is only an on-the-wire format, similar to the way regular > Bundles work now. > > > [1] http://dev.sugarlabs.org/ticket/1042 > [2] http://dev.sugarlabs.org/ticket/1053 > [3] http://wiki.sugarlabs.org/go/Features/Object_Bundles > > CU Sascha > > -- > http://sascha.silbe.org/ > http://www.infra-silbe.de/ > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iQEcBAEBAgAGBQJKbs+bAAoJELpz82VMF3DafE4H/3tMOMuT0Rb/n2BNxtR/nT0T > RqUXQjNDTK0eFgL5Y5ZgslBWszxf7SmronfKEayTXhthtzATsbwAtNxTt326Cv55 > nlDL8mOaFYohM8d8xT2j0ezOlukkK2FnK0Tmj3v3em388Ge54uJyKczAXC+LUY7K > BN6y/GCFQQCD4n1L9AnkVwv3xMSobAbaUvduYQj5CrgxOIXYvMXOGxxpZNR9eFSW > PdvDxACNeaejjNvGI+oAc/mCPlEx8bIDH4gJaQ5oMBg0RMo2T4sunmialsuw4NQ9 > XzDZOHHo41HnBWZX0vE2RMnTbTnc02ofR6k2za4xArhbbE4WYj8WwNRiBKCuW5I= > =B498 > -END PGP SIGNATURE- > > ___ > 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
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 05:14:57AM +, Aleksey Lim wrote: * it can't upgrade activities if they were pre-installed from native packages; it makes process of upgrading activities from .xo impossible Yeah, this is really a PITA. * sugar can have only one activity version installed at the same time That's being worked on, see bug #1042 [1] (patch available, but not merged yet) and #1053 [2] (fixed). i.e. it could be useful to have several versions simultaneously e.g. to start proper version when join request arrived(activity version of arrived request could be different to installed version) That's not implemented yet, of course, and needs further design decisions (esp. regarding the UI). [1] http://wiki.sugarlabs.org/go/Features/Activity_Objects This sounds a lot like what I imagined as a solution for the first problem: represent system-installed activities as a virtual Journal object - inside Journal / shell only, not exposed to activities or the datastore. What I don't get is how this depends on your Object Bundles proposal [3]. AIUI the latter is only an on-the-wire format, similar to the way regular Bundles work now. [1] http://dev.sugarlabs.org/ticket/1042 [2] http://dev.sugarlabs.org/ticket/1053 [3] http://wiki.sugarlabs.org/go/Features/Object_Bundles CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 01:49:15PM +0545, Daniel Drake wrote: > 2009/7/28 Aleksey Lim : > > Proposal is not about storing all versions but about possibility of > > storing not only one(last?) version and we can uninstall old versions > > by removing entries from journal. > > The journal can't delete activities that are installed by a package at > /usr/share/activities, and I also think it is unlikely that our users > would realise to do this even if it were possible. > > > There is no confusion, sugar is aware of what versions of particular > > activity it has by using datastore.find() method, so user can run > > `rpm update`, install any version by downloading .xo and sugar will run > > last version(when user create new activity instance) or run particular > > version(if activity object requires it). > > I was referring to confusion by deployments and those who are > diagnosing bugs and soforth. > > > btw, activity can declare, in activity instance object, what activity > > version(range) should be used with this particular instance object. > > Sounds like overcomplication. > > > In response to your question on how I think it should be done, I feel > that it's time to admit that packaging activities in this way is a > mess. We should leave packaging and the related complications to the > experts - packagers, and the package manager, and then we can stop > wasting our time on it. For some kind of cross-distro package manager > compatibility, someone recently raised the idea of PackageKit which > seems well worth investigating and given its rapid development can > probably be adapted to our needs. > > IOW I feel that the concept of sugar providing prepackaged binary > activities should die. +1, the way which was chosen by soas is a good example(all activities come from .xo bundles) > I think you would be a good person to work on > this, and it is an interesting problem. > > > Well we can't say to activity developers that they must write > > backwards-incompatible activities otherwise we won't host them on ASLO. > > In that case using compatibility ranges of versions could fix problem > > (w/o obliging developers write complicated code for > > merge/support-backwards-incompatibility). > > It's nice to have the freedom to post whatever I want on ASLO and I'm > not saying that should change. I'm free to write a buggy activity or > one that isn't sugarized and post it on ASLO. Even though my activity > is low quality and doesn't fit into the desktop, I'm welcome to post > it. The consequence is that my activity probably won't be included in > deployments, and I'll get some mails from testers making suggestions > how I could improve it, and maybe even some patches. I'd say that this > case is no different. > > > I like this idea only if all sugar users have 100% access to internet. > > And they can run "upgrade my 0.82 to 0.84 from internet" process by one > > click. But imho thats impossible in case of educational infrastructure > > around of the world. > > The responsibility of keeping all machines in sync can be handled by > the deployments, with the aid of good tools from Sugar/distro/OLPC. > This is how it already works in the field. It's not your problem, but > you could certainly help improve those tools and their concepts which > seem a bit neglected right now. Well, for me "0.82 doesn't work with 0.84" is very strong requirement btw it relates to [2] > > imho activities are the same kind of objects - user should have chance > > to edit/hack/share them like other sugar objects. > > Good point, but this seems to be beyond what sugar is capable of at > the moment and raises more questions. Perhaps once there is the > ability to modify your activity within sugar, the development activity > could offer functionality to package up the modified version and save > it in the journal. Exactly how the user could modify activities, how > the user-modified activity would be saved on-disk alongside the > original one, how they would be differentiated in the UI and how the > user could switch between the two seems to be out of scope of this > discussion -- or at least I can't see how it would be covered by your > proposal. Yeah it raise many new questions. In my mind we can do the first step on this road by creating activity-less Composite Journal entries[2](objects w/o activity DS field), so over activities(like Develop) can change activity's code inplace. And delegate(for the first time at least) all maintenance procedures (like what version I can change, what version is my backup copy) to users, they can do this if all activities will be Journal entries. [1] http://wiki.sugarlabs.org/go/Features/Decoupling_of_Sucrose [2] http://wiki.sugarlabs.org/go/Features/Object_Bundles#METADATA_file > Daniel > -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
2009/7/28 Aleksey Lim : > Proposal is not about storing all versions but about possibility of > storing not only one(last?) version and we can uninstall old versions > by removing entries from journal. The journal can't delete activities that are installed by a package at /usr/share/activities, and I also think it is unlikely that our users would realise to do this even if it were possible. > There is no confusion, sugar is aware of what versions of particular > activity it has by using datastore.find() method, so user can run > `rpm update`, install any version by downloading .xo and sugar will run > last version(when user create new activity instance) or run particular > version(if activity object requires it). I was referring to confusion by deployments and those who are diagnosing bugs and soforth. > btw, activity can declare, in activity instance object, what activity > version(range) should be used with this particular instance object. Sounds like overcomplication. In response to your question on how I think it should be done, I feel that it's time to admit that packaging activities in this way is a mess. We should leave packaging and the related complications to the experts - packagers, and the package manager, and then we can stop wasting our time on it. For some kind of cross-distro package manager compatibility, someone recently raised the idea of PackageKit which seems well worth investigating and given its rapid development can probably be adapted to our needs. IOW I feel that the concept of sugar providing prepackaged binary activities should die. I think you would be a good person to work on this, and it is an interesting problem. > Well we can't say to activity developers that they must write > backwards-incompatible activities otherwise we won't host them on ASLO. > In that case using compatibility ranges of versions could fix problem > (w/o obliging developers write complicated code for > merge/support-backwards-incompatibility). It's nice to have the freedom to post whatever I want on ASLO and I'm not saying that should change. I'm free to write a buggy activity or one that isn't sugarized and post it on ASLO. Even though my activity is low quality and doesn't fit into the desktop, I'm welcome to post it. The consequence is that my activity probably won't be included in deployments, and I'll get some mails from testers making suggestions how I could improve it, and maybe even some patches. I'd say that this case is no different. > I like this idea only if all sugar users have 100% access to internet. > And they can run "upgrade my 0.82 to 0.84 from internet" process by one > click. But imho thats impossible in case of educational infrastructure > around of the world. The responsibility of keeping all machines in sync can be handled by the deployments, with the aid of good tools from Sugar/distro/OLPC. This is how it already works in the field. It's not your problem, but you could certainly help improve those tools and their concepts which seem a bit neglected right now. > imho activities are the same kind of objects - user should have chance > to edit/hack/share them like other sugar objects. Good point, but this seems to be beyond what sugar is capable of at the moment and raises more questions. Perhaps once there is the ability to modify your activity within sugar, the development activity could offer functionality to package up the modified version and save it in the journal. Exactly how the user could modify activities, how the user-modified activity would be saved on-disk alongside the original one, how they would be differentiated in the UI and how the user could switch between the two seems to be out of scope of this discussion -- or at least I can't see how it would be covered by your proposal. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
On Tue, Jul 28, 2009 at 12:24:52PM +0545, Daniel Drake wrote: > 2009/7/28 Aleksey Lim : > > The problems that 0.84 has in case of activity versions are: > > > > * it can't upgrade activities if they were pre-installed from > > native packages; it makes process of upgrading activities > > from .xo impossible > > In reality Sugar's message is confusing here and I don't think any > distributor will mix-and-match the two ways of installing activities. > (either they'll use distro packages and disable .xo, or they will > exclusively use .xo e.g. OLPC). Well, thats question not only about distributor's comfort but about users possibility to install new activity version. Otherwise what your suggestion is? * for pre-installed activities, using only non-xo methods to update * using only non-xo activities * using only xo activities > This is a larger problem and I don't think yours is a solution, since > it will result in wasted disk space Proposal is not about storing all versions but about possibility of storing not only one(last?) version and we can uninstall old versions by removing entries from journal. > and we still end up with the > confusion of how activities can be installed and which one is being > used. There is no confusion, sugar is aware of what versions of particular activity it has by using datastore.find() method, so user can run `rpm update`, install any version by downloading .xo and sugar will run last version(when user create new activity instance) or run particular version(if activity object requires it). btw, activity can declare, in activity instance object, what activity version(range) should be used with this particular instance object. > > * sugar can have only one activity version installed at the same > > time i.e. it could be useful to have several versions > > simultaneously e.g. to start proper version when join request > > arrived(activity version of arrived request could be different > > to installed version) > > I think this calls for wider discussion. Having multiple versions of > the same activity installed sounds silly. Instead, activity designers > should be encouraged to strongly avoid making backwards-incompatible > protocol changes, just like the principles of any other software > designer. Once everything is compatible, this problem goes away. Well we can't say to activity developers that they must write backwards-incompatible activities otherwise we won't host them on ASLO. In that case using compatibility ranges of versions could fix problem (w/o obliging developers write complicated code for merge/support-backwards-incompatibility). > Sugar > should continue to make no promises about interoperability between > different major releases (e.g. no promises about 0.82 talking to 0.84) > and hence if it is necessary, activity developers are allowed to break > compatibility once every 6 months, which should be more than enough. I like this idea only if all sugar users have 100% access to internet. And they can run "upgrade my 0.82 to 0.84 from internet" process by one click. But imho thats impossible in case of educational infrastructure around of the world. > Finally, I personally don't like the idea of having activities (as in > applications) in the journal. The journal is for recording what the > user has done. imho activities are the same kind of objects - user should have chance to edit/hack/share them like other sugar objects. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity as regular objects proposal
2009/7/28 Aleksey Lim : > The problems that 0.84 has in case of activity versions are: > > * it can't upgrade activities if they were pre-installed from > native packages; it makes process of upgrading activities > from .xo impossible In reality Sugar's message is confusing here and I don't think any distributor will mix-and-match the two ways of installing activities. (either they'll use distro packages and disable .xo, or they will exclusively use .xo e.g. OLPC). This is a larger problem and I don't think yours is a solution, since it will result in wasted disk space and we still end up with the confusion of how activities can be installed and which one is being used. > * sugar can have only one activity version installed at the same > time i.e. it could be useful to have several versions > simultaneously e.g. to start proper version when join request > arrived(activity version of arrived request could be different > to installed version) I think this calls for wider discussion. Having multiple versions of the same activity installed sounds silly. Instead, activity designers should be encouraged to strongly avoid making backwards-incompatible protocol changes, just like the principles of any other software designer. Once everything is compatible, this problem goes away. Sugar should continue to make no promises about interoperability between different major releases (e.g. no promises about 0.82 talking to 0.84) and hence if it is necessary, activity developers are allowed to break compatibility once every 6 months, which should be more than enough. Finally, I personally don't like the idea of having activities (as in applications) in the journal. The journal is for recording what the user has done. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Activity as regular objects proposal
Hi all, The problems that 0.84 has in case of activity versions are: * it can't upgrade activities if they were pre-installed from native packages; it makes process of upgrading activities from .xo impossible * sugar can have only one activity version installed at the same time i.e. it could be useful to have several versions simultaneously e.g. to start proper version when join request arrived(activity version of arrived request could be different to installed version) So, I think [1] could solve these issues. Suggestions/comments are welcome. [1] http://wiki.sugarlabs.org/go/Features/Activity_Objects -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
