C. Scott Ananian wrote: > On 8/6/07, Yoric <[EMAIL PROTECTED]> wrote: >> On Mon, 2007-08-06 at 03:12 -0400, C. Scott Ananian wrote: >>> On 8/3/07, Yoric <[EMAIL PROTECTED]> wrote: >>>> With this in mind, I intend to be able to reference >>>> * the package itself (to be able to download it, from Firefox or from >>>> anywhere else) >>> http://canonical.source/alice.in.wonderland.zip
As an aside, but also because zip files seem to be complicating some other use cases, in my tests zip files aren't substantially smaller than JFFS2's normal zlib compression. I listed some examples here: http://lists.laptop.org/pipermail/library/2007-July/000073.html And a script to test it out for yourself here: http://svn.colorstudy.com/home/ianb/olpc/jffs2size.py The zip files are a bit smaller, probably because it can compress entire files while JFFS2 only compresses 4K chunks. Notably tar.gz files are substantially smaller than either, but I don't believe tar files are appropriate for storing pages since it's harder to access individual files. Zip files would be faster to download, but not much smaller if you are connecting with a web server and client that know gzip compression (there will be some extra overhead from all the headers). If you have Keep-Alive working on both sides too, the added latency won't be too bad I'd think. (Though maybe HTTP pipelining would improve things even more? Not many clients know how to do HTTP pipelining from what I understand, but I'm a little fuzzy on the whole thing.) More of a problem is actually figuring out what all pages you want or need. You can download them incrementally, which is nice (you can view the first couple pages, for instance, while the rest is downloading). But if you have to follow <link rel="next"> to get all the pages that's going to be somewhat annoying to handle. A complete enumeration would be nice to have up-front. If the server and client could agree on passing around a tarball, that would be even nicer, but that's something we'd have to rig up on our own. I can imagine a header: X-Tar-Fetcher: http://this.server/tarball.cgi And, seeing that header and if the client knows it has a bunch of files to fetch, it would fetch: http://this.server/tarball.cgi?compress=gz&url={url1}&url={url2}&;... And the server would create a tar.gz file from all those urls. Anyway, just one possible solution to the possible problem of getting lots of files over HTTP. >> Once the book has been downloaded locally or, say, added to a >> hypothetical peer-to-peer library, do you refer to it with the same http >> URL or with a file URL (respectively a peer-2-peer protocol URL) ? > > The same URL. That's the whole point of URLs! The hypothetical > peer-to-peer library is just a fancy type of web cache: resources > which live canonically at (say) http://cscott.net can actually be > obtained from my neighbor (say) or the schoolserver. But this is done > via the standard http proxying and caching mechanisms. We *could* > return (say) a special http header which indicates that this resource > is peer-to-peer cachable, but I'd prefer not: I still don't see how > "books" are fundamentally different from other web content. It seems > more likely that (for example) a schoolserver would be configured > (server-side) to preferentially cache some content which it knows to > be the textbooks for the class. I wrote up some thoughts for this here: http://wiki.laptop.org/go/Content_repository#Proposed_implementation When you have poor connectivity, you want the children to be able to get a complete/consistent set of resources when they do have connectivity. For instance, if they have material they are supposed to study you want them to be able to "take it home" so to speak, by preloading their laptop with that material. Definitely fetching it from peers is a possibility. But that can't work predictably; you can never be sure what your peers will have, or if they'll be around. I suspect this will annoy teachers most of all. The idea I was thinking of is to have some way to enumerate a set of resources, and then use that as the basis for pre-fetching. A book is an obvious set of resources (all the pages in the book), but you could also do it chapter-by-chapter, include articles or pages or Javascript tutorials, or whatever. I played around with a proxy that looked for this kind of markup, and added links to cache and uncache pages based on that. The proxy itself was kind of lame, though. Anyway, for the curious: http://svn.colorstudy.com/home/ianb/OLPCProxy -- Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org : Write code, do good : http://topp.openplans.org/careers _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
