jmr wrote:
Hi - having had some discussions offline with Shawn and Brock about
this, I'd like to get started and here is what I'm proposing:
I will put in place the mime type support for packagemanager, using the
API suggested by Shawn with just a wrapper implementation consuming the
basic config file used in the prototype. As soon as the API is available
I can swap it in and start using MimeType files with the JSON layout
Shawn has proposed.
I will maintain this is a separate workspace and will only check it in
when we have the new API in place. Anyone interested can grab the webrev
in progress.
I will be starting work on the authority APIs today. I've been delaying
because I've been discussing some transport changes with j that I
thought might relate to the authorityinfo object we've been discussing.
Suggested Mimetype:
----------------------------------
To cover both authority and package installs:
Mimetype: application/vnd.opensolaris.pkg-info
Suffix: .p5i
I don't think the mimetype is good since pkg(5) is cross-platform.
Instead, I would suggest application/vnd.pkg5.info; especially since
that omits a trademark.
MimeType File Needs to Contain:
------------------------------------------------------
authority_name: optional
origin_urls: one or more required.
pkg_names: list of package names to install from this authority
Format handled will be in old config style initially, until new API is
available which consumes JSON based files.
The assumption is that the authority info can be obtained from the
authority/0 query, so authors of the MimeType files just have to put in
the origin_url and pkg_names to the MimeType file.
Packagemanager:
------------------------------
Packagemanager launched with a -i <mimetype file path> will use the
following API to get the information it needs to display a WebInstall
Dialog to the user.
-i <pathname|origin_url>
...should work since I plan on implementing the method such that it can
handle either.
/api_wrapper.get_mimetype_info(<path to mimetype file|origin_url>)
/- returns tuple of AuthorityInfo object [1] and optional list of
packages to install.
I'd prefer not to have mimetype in the method name as that is really
irrelevant to what the method is doing. Perhaps parse_authority_info()?
Note: The list of packages returned needs to have been setup so
/api.plan_install() /can work with them:
- If authority in file is the default authority the package list entries
just need to be, <pkg_name>
- If authority in file is NOT the default authority the package list
entries need to be, pkg:://<authority_name>/<pkg_name>
I question allowing files to override the user's preferred authority.
This could cause software to be installed that the user does not want,
or a newer version of a program.
- The AuthorityInfo object as well as all the authority fields already
discussed [1] should contain a status field to indicate if its
registered or not. If it is not then this will be passed to:
/api_wrapper.set_authority(AuthorityInfo)
I don't think status clarifies the field intent well enough; it should
be something more specific either through the name or the value it is
set to.
/Workflow for the user will be [2]:
------------------------------------------------------
xDesign is working on preliminary designs, but in essence I think it
will go like this:
- Click on Mimetype web link in browser
- Packagemanager is launched in WebInstall mode, so only a simple
WebInstall dialog is displayed to the user not the full PM
- WebInstall Dialog, lists out what is about to happen, if a new
Authority needs registered and what if any packages are about to be
installed. Click Cancel or Proceed.
- On Proceed, if new Authority required, popup New Authority Dialog,
which allows user to specify Authority name (though one could be
suggested from info in AuthorityInfo file) and SSL key and cert if
required. After this completes launch Install dialog to install packages.
That leads to a double confirmation if all of the required information
about the authority has already been provided. I think it would be
better to:
* if all the required information has been provided, confirm the action
and provide a choice to:
-- edit the authority information and continue
-- immediately execute the requested action
-- cancel
* if not all the required information has been provided:
-- edit the authority information and continue
-- cancel
One remaining concern I have about the pkg_names aspect is that this is
likely to overlap with the functionality that was recently posted about
by Dan Price [1]. That means that the implementation for this may
change a lot in the future.
--
Shawn Walker
[1] http://markmail.org/message/5ezs6smi43imtbdt
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
