<div dir="ltr">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.<br> <br><div>- Eben</div><div><br></div><div><br><div class="gmail_quote">On Thu, Jul 17, 2008 at 11:04 AM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div dir="ltr">I see. Yes, I think that works.<div><br></div><font color="#888888"><div>- Eben</div></font><div><div></div><div class="Wj3C7c"><div><br><br><div class="gmail_quote">On Thu, Jul 17, 2008 at 10:58 AM, Tomeu Vizoso <<a href="mailto:tomeu@tomeuvizoso.net" target="_blank">tomeu@tomeuvizoso.net</a>> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div>On Thu, Jul 17, 2008 at 4:50 PM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com" target="_blank">eben.eliason@gmail.com</a>> wrote:<br> ><br> ><br> > On Thu, Jul 17, 2008 at 5:31 AM, Tomeu Vizoso <<a href="mailto:tomeu@tomeuvizoso.net" target="_blank">tomeu@tomeuvizoso.net</a>> wrote:<br> >><br> >> On Thu, Jul 17, 2008 at 3:19 AM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com" target="_blank">eben.eliason@gmail.com</a>><br> >> wrote:<br> >> > Yeah, I'm not sure that this is expected behavior (I would expect not).<br> >> >  The<br> >> > intent is that a "customization" upgrade would allow additive changes to<br> >> > the<br> >> > favorites ring, for instance to allow a school to ensure that every kid<br> >> > has<br> >> > brand new activity X in the ring on the first day of class (if the kids<br> >> > later remove it, that's up to them, of course).  The question, then, is<br> >> > if/why installing that RPM behaved in the manner of a customization<br> >> > instead<br> >> > of a basic software update.<br> >> > Tomeu, do you know how this is expected to work?<br> >><br> >> When kids update to a version that has the notion of favorites, we<br> >> don't want to show the favorites screen empty. That's why we added<br> >> code for adding the activities mentioned in activities.default.<br> ><br> > I'm OK with this if it's a one-time change.  In other words, it should check<br> > for an empty favorites list and apply the defaults if none exist.<br> ><br> >><br> >> Also, when you update to a newer version, favorites.default might<br> >> change so we merge it again with the users favorites. We don't know if<br> >> an activity present in activities.default but not in the favorites was<br> >> removed by the user or added by the school/deployer.<br> ><br> > Well, it depends on the use case.  Is editing favorites.default the intended<br> > way for a country or school to manage updates?  If so, then I suppose that<br> > this is correct.  If not, then we should really only be setting the<br> > favorites from the default file when no favorites are set at all (should<br> > only happen once), and otherwise do a merge from a favorites list on a<br> > customization key instead.<br> <br> </div></div>What I understood is that the customization key would install some<br> activities and a activities.default file. When Sugar starts up, it<br> checks if activities.default has changed since last time we merged it,<br> and if so, we merge it again. Is this right?<br> <br> Regards,<br> <font color="#888888"><br> Tomeu<br> </font></blockquote></div><br></div></div></div></div> </blockquote></div><br></div></div>