Sorry for missing this thread--I've been out the past few days.
I'll impose a summary, in the interest of bringing this topic to a
close.
1. POST is the ioctl(2) of REST. If we want to move away from
/filelist/0 to something GET-based and taking advantage of
pipelining, that's fine. /filelist/0 needs to be supported for
the next 18 months, but it can be deprecated.
2. Apache's combined log is not a complete log solution. It's easy
to criticize /filelist/0, but that's only one of the problems with
the limited, non-structured logging we're presently doing.
Failures, restarts, correlation, image identification are all
missing (and likely to remain missing) in the combined log format.
3. Akamai isn't the only CDN in the world. It's not even the only
one Sun does business with--and all of them are interested in
doing compute-in-the-cloud. Assertions about GET versus POST for
CDNs are short-term assertions. More importantly, there is a
distinct pricing calculation to be made between directly-served
and CDN-served data that not every pkg(5) depot operator will wish
to make.
4. None of the CDNs does a good job everywhere. That's why one of the
next steps is to do content mirrors, particularly for
pkg.opensolaris.org, so that we can have local mirrors in regions
interested in OpenSolaris. Since we have strong hashes (and will
use stronger ones still, and signing), any mirror can be
distrusted/trusted in a precise fashion. I would like to see
/filelist/0 or successor handle partial success better.
Since we do want to support content mirrors, which means that the
/filelist/0 operation or its successor happen on a machine other than
the authority's origin system, I actually think it's more important
that GET /manifest/0 declare the operation the manifest is being
retrieved for, and that we introduce HEAD /manifest/0 to register the
reuse of a manifest for some other purpose. Improving /filelist/0 to
show some version arc is okay, but will become less useful as
mirroring becomes supported.
- Stephen
--
[EMAIL PROTECTED] http://blogs.sun.com/sch/
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
