On Thu 08 May 2008 at 07:51PM, Danek Duvall wrote:
> We've all been thinking at least a little about how to improve the current
> filelist. Dan and I are both strong proponents of making it more RESTful,
> and all of us want it to be more observable (right now the logs are
> completely opaque wrt the filelist ops). We've been talking about
> decorating the filelist ops to improve it in both aspects, but I still
> think that individual file ops are the way to go, if we can get the
> performance to match what we've got. Perhaps CherryPy can give us that.
I think we might be able to do a hybrid approach-- we might want
a batch op for "get the whole package all at one" as well as
"get a file at a time."
I've approached this problem because I've been doing some rudimentary
looking at the server logs and it's annoying to see this (elided for
clarity):
[07/May/2008:18:52:41 -0700] "POST /filelist/0 HTTP/1.0" 200
[07/May/2008:18:52:36 -0700] "POST /filelist/0 HTTP/1.1" 200
[07/May/2008:18:52:43 -0700] "POST /filelist/0 HTTP/1.1" 200
As you can see, all the stuff you might want to know is buried
in the POST operation. For those not familiar with what RESTful means,
well, it's the opposite of this-- that is to say, the URL should provide
the context.
So my short-term proposal is to alter this to something like:
POST /filelist/0/[EMAIL PROTECTED]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is just several lines of code change in the client; the
server will just ignore the extra part of the URL, except that it
will log it. This will help us understand which packages are
seeing the most downloads.
However, I've been thinking that an even more RESTful implementation is
possible-- we could avoid POST entirely, and use GET; for example:
GET /filelist/0/SUNWgnome-img-editor-help-es/0.5.11%2C5.11-0.86/all
^^^ ^^^^
This could mean: get all files associated with this package (this is the
"install fresh" case). This could even be mapped as:
GET /package/0/SUNWgnome-img-editor-help-es/0.5.11%2C5.11-0.86
^^^^^^^^
Note that this could then be served by an HTTP cache or even a
plain old apache instance, since we have effectively altered a
non-static request into a completely static one.
For the upgrade case, we're trying to be bandwidth efficient, and
so we avoid fetching whole packages. In that case, the client could
either do the individual GETs, or ask a smart server for a specific list
of files in a RESTful way:
GET /filelist/0/SUNWgnome-img-editor-help-es/0.5.11%2C5.11-0.86/1:2:7:9
^^^^^^^
This could mean "get the files associated with the 1st, 2nd, 7th, 9th
file actions in the manifest" (this would rely on the client and server
both obeying a predictable sort order for files in a manifest).
Just some thoughts that have occured to me... Reactions?
-dp
--
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
