On Mon, 2007-06-25 at 12:25 -0400, C. Scott Ananian wrote: > > > mDNS *is* multicast. But the blobs won't be exposed over mDNS, that > is > > far to much data for a protocol like that. > > Really? Do we know that? What's a typical 0-day patch look like? > Have we tried to see how few bits it could be squashed into?
The broadcast just contains a product/version ID - doesn't have to include the entire update. No more expensive than the presence stuff we have today. > > > Binary diffs seem much less useful. They enforce a specific base > version > > that you have to have around, and they enforce the direction of > upgrade. > > This is *exactly* why we need to have the big picture view. My > understanding is that we *are* expecting all laptops to have identical > bases, that the upgrade propagation rate and upgrade (in)frequency > will be sufficient that all laptops will be running the same version > of the software (save for a few stragglers who go on a long trip for a > few weeks), and that the vserver copy-on-write mechanism will be used > to perform rollback (so that we only need to worry about the forward > direction). I think that what Alex here can do it either way. You could use the vserver copy on write stuff if you want to use the hammer of a filesystem or you could use the image code he has to move it back whether or not the copy on write stuff is there. Or even after you have "committed" via vserver. I strongly suggest that we make sure that we keep the ability to go both directions. It gives us a lot more flexibility down the road, and for the countries and our users as well. > > I'm not saying that my assumptions are correct. But I feel that > deciding file formats before we've come to a big picture consensus may > be premature. > > > If you can cheaply generate at runtime (on the client) a minimal > diff > > between any two versions you can avoid storing unnecessary > information, > > Not sure exactly what you're getting at here: that we transfer > complete blobs over the network but store them on the XO as binary > diffs? My working assumption is that network and storage costs on the > XO should be minimized as much as possible. Transferring complete > blobs fails on these grounds. When you hear "complete blobs" can you describe what you mean? I suspect that you're thinking of something different than what Alex has actually implemented. --Chris _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
