* Shawn Walker <swal...@opensolaris.org> [2008-12-23 20:56]: > Stephen Hahn wrote: >> I've been looking at some of the packaging interactions and >> suggestions for enhancement we've been accumulating, and wanted to get >> some feedback on a potential new operation (and file-type): >> authority/0. >> >> authority/0 is a new server operation that returns a formatted >> response, with the following pieces of information: >> >> - Repository's authority name, such as "opensolaris.org". Required. > > How does this impact packages in the repository that are being > published or re-published on behalf of another authority?
I had thought I had categorized those into the vendor/ namespace, once upon a time. >> - Repository full name. Optional. >> >> - Repository description. Optional. > > How do you envision l10n support working? Should this operation > return all locale-specific values and the client filter to its own, or > should the client provide the locale information and let the server > filter it? The general issue with localization is that one can't assume that all locales become available at the same time nor that the provisioning of translations are all done by the same party. (That is, I worry more about the process impact than the technical one.) Although this feature needs a generation number or timestamp to distinguish changes for other attributes, authority/0 also needs one so that new description arrival causes updates. (Implies that authority/0 may be part of a larger refresh sequence.) So, we can either put all the localizations into the authority/0 response, or have an auxiliary authority response that's filtered. In the former case, than means there's an assembly step by the repository operator. >> - List of one or more origin URLs for repositories. Optional, for >> authorities that do not use the network protocol to distribute >> packages. (We don't support that yet, of course.) > > What would these be called; repository mirrors instead of content mirrors? Or full mirrors. One other aspect to this is whether or not search URLs should also be hived off, since server search is a commitment. >> - Update period. Optional, but recommended, so that clients can tune >> their refresh frequency. > > How will this be expressed? crontab-like? or a pre-defined set of > keywords? Number of seconds between refreshes, probably. >> - License/terms of service URL. Optional. > > Should repositories be able to require acceptance of these terms by the > client and the depot provide a way to post a response that can be logged? I'd argue that's part of access control, and not of informational operations. >> - Registration URL/protocol. The pkg.sun.com/register service is >> actually also a web service that clients can connect to to obtain a >> key-certificate pair. It's more ad hoc than I would like, but could >> be used to allow client integration under a specific >> "com.sun.pkgcert" tag while we look for some more general facilities. > > Maybe we should pre-define an XML-RPC interface for registration > services to comply with so that clients can generically register? I > cringe at using SOAP. Noted (although we don't have a SOAP interface, just a primitive set of parseable responses). >> Impacts: >> >> 0. The authority name is set by the publisher, and is not left to the >> client. So >> >> pkg image-create -a opensolaris.org=http://pkg.opensolaris.org/dev \ >> /tmp/myimage >> >> is equivalent to >> >> pkg image-create -a http://pkg.opensolaris.org/dev /tmp/myimage > > If they specify it, could we use that as the "nickname" or "full name" > override? Yes, that would be fine. >> 1. The authority values in cfg_cache become overrides. For the most >> part, the cfg_cache values become unnecessary. (Need input about >> full name and description from Tom M, since Update Center is the >> primary consumer of these values.) > > How does this fit with the plans for SMF-integration with cfg_cache in > doc/image.txt? We need to work through this. authority/0 presents a lot more manipulatable data that the repository operator needs to configure. >> 5. The return value of authority/0 is useful as a standalone >> document for bootstrapping access to an authority. That suggests >> that the return value should be useful in a file form. We've used >> XML with success/controversy in other places for properties like >> this, but we could also use YAML or make a mini-language. > > Python YAML is slated to be integrated for "2009.04": > > http://opensolaris.org/jive/thread.jspa?threadID=81337 See my other response (JSON) in this thread. >> Assuming we have a document format, we should introduce a MIME >> type, like application/vnd.opensolaris.pkg-authority (or >> application/x-pkg-authority), and a standard suffix, like >> .pkgauth (or something). >> >> At that point, >> >> pkg set-authority -a file_or_url >> >> seems to become a useful extension. (pkg(1) is not currently, >> however, an ideal client for "one click" actions out of the >> browser, so we probably need to have a small GTK+-based helper as >> well.) > > I'd like to ensure that we support multiple formats here, and require > clients to request a specific one. Why do you want to support multiple formats? (Or do you mean allow the possibility of multiple formats over time?) > This also makes me wonder if the right request path style was chosen: > > authority?version=0&file_format=yaml > > instead of: > > authority/0/yaml I thought we liked to jam all optional parameters into headers. :) - Stephen -- s...@sun.com http://blogs.sun.com/sch/ _______________________________________________ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
