John Rice wrote: > Shawn Walker wrote: >> John Rice wrote: >>> .pkginfo supported fields from Stephens authority/0 mail: >>> ------------------------------------------------------------------------ >>> authority_name: Required >>> authority_fullname: Optional >> >> What if the authority name here conflicts with an authority they >> already have? Will that update the mirrors and origin_urls of that >> authority? >> >> I don't think this information should be required since if the >> origin_url(s) points at a depot server that supports authority/0, then >> we can get this information automatically. > Currently we are checking the installed authorities on the machine and > using the origin_url as the key, irrespective of the authority_name. > > I took "authority_name: Required " from Stephen's proposal, so I'll > leave him to explain why he thought it should be required. If we are > moving to the repo owner specifying the authority_name then this could > make sense, otherwise I would prefer to stick with using the origin_url > as the key and change this field to Optional.
My understanding was that Stephen was saying that information was required because the server *must* provide it. However, in your context, I think it has a completely different application since you are dual-purposing a single file to both add/update authority information and install packages. >>> related_origin_urls: Optional >>> mirrors: one or more, Optional >>> update_period: Optional >>> license_url: Optional. >>> registration_url: Optional >>> registration_protocol: Optional >>> pkg_names: list of package names to install from this authority, the >>> PM supports install of the latest package so only the package name is >>> required at present, do we want/ need to support full fmri's here?? >> >> Yes, I believe full FMRIs should be supported. What delimiter are you >> going to use? It should be a character that isn't allowed in FMRIs >> (i.e. you can't use a ',' or ':', etc.). > What do you suggest as a delimiter? It may be better to use individual entries to avoid the delimeter issue altogether, since we may change what characters are allowed in the future. In other words: pkg_name: foo pkg_name: bar pkg_name: baz Alternatively, I have no better suggestion than whitespace (tab or space) or a ';' at the moment. >> I don't think that this logic should be implemented only in the gui >> (not even for initial implementation); instead it needs to be >> implemented as part of the api, and both the cli and gui should >> support it. I could envision the install subcommand of the cli taking >> an additional -i or --info option that would contain a URL or filepath >> to a package information file. The gui would work the same. > The GUI and CLI will handle this in different ways which is fine, the > underlying authority addition and/or package install will continue to > use the underlying API's (authority API's are not yet available). For > instance when adding an authority we'd like to at least detect if its > using https and give the user the option of specifying SSL key and Cert. > When we bind the mimetype the result of clicking on a web link of this > mimetype is for the file to be downloaded onto the users /tmp dir and > the bound application to be launched with this file path. That is what > we are currently handling and can have it require a -i or --info option. > We where not planning on handling a URL though we could. The authority operation and the related APIs will likely be the next thing I work on. As to your comments about ssl key and cert, I think that's quite valid. However, we need to be able to handle that in a more generic way. Specifically, I think we ought to have a way to generically represent each scheme supported by the client API, and any corresponding, applicable properties that are specific to it. More schemes are coming the future, and I'd like to be better prepared to support them. Can you work with Brock to ensure that this work gets into the API first? I'd really like to see this in the API for the first implementation, instead of straight to the GUI, and then file a bug to have the CLI support this functionality through the API? >> Finally, I think it's too early to implement this, though I'm all for >> planning and discussing it. My personal belief is that both the >> authority/0 changes and the configuration file format changes need to >> be in place first. > MimeType support is part of the OpenSoalris.Next requirements for the > IPS GUI and we'd like to get moving on it if at all possible. > The authority/0 changes do not need to be in place for the mimetype > handling, we just need to agree on the fields that will be supported. I understand your strong desire to advance the GUI as quickly as possible to provide a better user experience, but it seems awkward, to me, to implement functionality that is attempting to depend upon or mirror other functionality before it's implemented. > With regard to the configuration file format changes, what is the > timescale for this? Again its easy for us to switch the processing of a > ConfigParser style config file to a JSON based format when its available. configuration file format and the authority operation are next on my list to implement, so likely mid-February. My main problem with the flat format proposed is that it is not very extensible if we decide we need more functionality later. I could use your feedback on the "Proposed pkg.depotd cfg_cache design changes / assertions" thread I posted on 1/13/2009. Cheers, -- Shawn Walker _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
