On Fri, May 09, 2008 at 12:17:32AM -0700, Dan Price wrote: > GET /filelist/0/SUNWgnome-img-editor-help-es/0.5.11%2C5.11-0.86/1:2:7:9 > ^^^^^^^
This is certainly far more restful than what we have. Dan and I had a discussion yesterday about whether explicitly listing the file indices was better, or whether we should ask for all the files in the package arc -- the difference between the package version you're coming from and the version you're going to. Specifying the arc would require that two package names and two package versions be specified -- to handle rename. This would degenerate to one package name and version in the case of an initial install. I think they're roughly equivalent, though they have slightly different disadvantages. With Dan's approach, you may end up with a long URL if you have a large number of files needing download. This might happen in a package with a lot of small files, such that many files would fit into the default 5MB filelist limit. With my (Stephen's really) approach, you'd have to have the manifest of the old package version on the server in order to compute the difference (the client is guaranteed to have it, the server isn't). And if that difference amounted to more than 5MB, you'd have to make multiple requests, distinguished by, say, a serial number. And that's kinda ugly. Having the arc present in the log, though, gives you more information about what people's upgrade paths are, how long they're staying at old versions, and so on. > (this would rely on the client and server both obeying a predictable sort > order for files in a manifest). A predictable, stable (over time) sort order is something that was bugging me (both proposals would need it), but then it occurred to me that we could just sort on the hash itself. We could also extend the individual file notation to include ranges. Something like "1-5:7:9" would represent the first five files, the seventh, and the ninth. "1-300" could end up being the "all" equivalent (or however many files there are). It doesn't solve the degenerate case of something like 1:3:5:7:9:... being very long, but ... I still think that fully pipelined file ops are a cleaner way to go, if we can actually use such a construct in Python. So I'm still curious if CherryPy will provide that for us, server-side, leaving us only needing a client-side implementation. Danek _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
