Christopher Blizzard wrote: ... > So notes on the proposal: > > 1. There's a lot in here about vserver + updates and all of that is > fine. But we've been pretty careful in our proposals to point out that > how you get to the bits to the box is different than how they are > applied. I don't see anything in here around vserver that couldn't use > alex's system instead of rsync. So there's no added value there. > I would agree that vserver is largely orthogonal, with the assumption that we don't do a direct-to-file-system update (already discussed and agreed).
My understanding here is that Alex's system is currently point-to-point, but that we don't yet have any way to distribute it on the mesh? That is, that we are looking at a research project to determine how to make it work in-the-field using some form of mesh-based discovery protocol that's going to try to optimise for connecting to local laptops. I personally don't care which way we distribute, but I'm wary of having to have some mesh-network-level hacking implemented to provide discovery of an update server. I'd be much more satisfied if there were something that could hook into some Jabber/Tubes/whatever distributed service that's already written and ready-to-go. Of course, we wouldn't be able to do the nearest-neighbour update mechanism without the mesh topology information, but I'd be tempted to make that topology information a more general mechanism that any application could access, rather than making it a part of this particular daemon, and I'd be tempted to make that happen later rather than earlier. I could have mis-read the comments and status on Alex's system, though. After all, it's just a custom per-file rsync operation, so it should be possible to update from almost any source, just as with rsync. It is the auto-discovering and the like that sound rather low-level and fragile to me. In other words, if we wanted to run s/rsync/Alex's system/ over Ivan's proposal, I'd be largely fine as long as the protocol is stable and reliable. My concern is in trying to leap directly to the optimised laptop-to-laptop case with low-level network operations. > I > think that we need something that's actually designed to solve the > problems at hand rather than seeing the hammer we have on the shelf and > thinking that it's obviously the right solution. > Fair enough AFAICS, as long as the protocol can be robust and stable within the time frame. > Basically aside from the vserver bits, which no one has seen, I don't > see a particular advantage to using rsync. In fact, I see serious > downsides since it misses some of the key critical advantages of using > our own tool not the least of which is that we can make our tool do what > we want and with rsync you're talking about changing the protocols. > Hmm, interestingly I see "using our own tool" as a disadvantage, not a huge one, but a disadvantage nonetheless, in that we have more untested code on the system (and we already have a lot), and in this case, in a critical must-never-fail system. For instance, what happens if the user is never connected to another XO or school server, but only connects to a (non-mesh) WiFi network? Does the mesh-broadcast upgrade discovery protocol work in that case? Enjoy, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
