Actually, I have one more concern. It seems to me we might be better off checking against a hash of the file, instead of a timestamp. We don't want to continually merge new favorites with every OS update, but that's exactly what we'll do if we only check the timestamp on the favorites.default file, right? By checking a hash, we ensure that someone (either us, by "shipping" a new favorites.default, or the country, via a customization key) intended a new merge to happen.
- Eben On Thu, Jul 17, 2008 at 11:04 AM, Eben Eliason <[EMAIL PROTECTED]> wrote: > I see. Yes, I think that works. > - Eben > > > On Thu, Jul 17, 2008 at 10:58 AM, Tomeu Vizoso <[EMAIL PROTECTED]> > wrote: > >> On Thu, Jul 17, 2008 at 4:50 PM, Eben Eliason <[EMAIL PROTECTED]> >> wrote: >> > >> > >> > On Thu, Jul 17, 2008 at 5:31 AM, Tomeu Vizoso <[EMAIL PROTECTED]> >> wrote: >> >> >> >> On Thu, Jul 17, 2008 at 3:19 AM, Eben Eliason <[EMAIL PROTECTED]> >> >> wrote: >> >> > Yeah, I'm not sure that this is expected behavior (I would expect >> not). >> >> > The >> >> > intent is that a "customization" upgrade would allow additive changes >> to >> >> > the >> >> > favorites ring, for instance to allow a school to ensure that every >> kid >> >> > has >> >> > brand new activity X in the ring on the first day of class (if the >> kids >> >> > later remove it, that's up to them, of course). The question, then, >> is >> >> > if/why installing that RPM behaved in the manner of a customization >> >> > instead >> >> > of a basic software update. >> >> > Tomeu, do you know how this is expected to work? >> >> >> >> When kids update to a version that has the notion of favorites, we >> >> don't want to show the favorites screen empty. That's why we added >> >> code for adding the activities mentioned in activities.default. >> > >> > I'm OK with this if it's a one-time change. In other words, it should >> check >> > for an empty favorites list and apply the defaults if none exist. >> > >> >> >> >> Also, when you update to a newer version, favorites.default might >> >> change so we merge it again with the users favorites. We don't know if >> >> an activity present in activities.default but not in the favorites was >> >> removed by the user or added by the school/deployer. >> > >> > Well, it depends on the use case. Is editing favorites.default the >> intended >> > way for a country or school to manage updates? If so, then I suppose >> that >> > this is correct. If not, then we should really only be setting the >> > favorites from the default file when no favorites are set at all (should >> > only happen once), and otherwise do a merge from a favorites list on a >> > customization key instead. >> >> What I understood is that the customization key would install some >> activities and a activities.default file. When Sugar starts up, it >> checks if activities.default has changed since last time we merged it, >> and if so, we merge it again. Is this right? >> >> Regards, >> >> Tomeu >> > >
_______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
