Thanks for the comments Shawn, responses below: JR
Shawn Walker wrote: > 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. Ok, I understand. The question is for a MimeType file do we just need the origin_url and assume that we will use this to check if the Authority is set on the users system and if not request a full PkgAuthority object (containing all the fields already mentioned for an authority) via an Authority API, get_authority_info(origin_url), making a authority/0 query against the depot. Once we have this PkgAuthority object then we can use the info it contains to display the Add Authority dialog to the user (at that point the user might add SSL Key and Cert and/or adjust mirrors), then submit it using the Authority API to add the new authority. > >>>> 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'll look at your JSON stuff and see how this fits, happy to to have list as you suggest instead of delimiters, if this works. > >>> 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. Ok, if we are working with a PkgAuthority returned by an Authority API then if it has a scheme enumeration we could use that. > > 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? I agree and will contact Brock about it. > >>> 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. I understand, I think that we can move forward without the authority/0 support in a depot from day one, but the hope is that it would be available in the near term so we can go the route of keeping the content of the MimeType file really simple (just an origin_url and an optional list of packages to install) and then query the server via a suitable API to get all the Repo info. > >> 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. Will look at that tomorrow. > > Cheers, _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
