Thanks Shawn - comments below:
I have got some mockups from Jenya in xDesign and so can start on the
Web Installer dialog on Monday. I'm also sorting out the Gnome stuff
that needs changed on the Desktop to support all this and will get it
checked into the gnome-2-24 branch.
JR
Shawn Walker wrote:
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.
Great
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.
Ah ok - I'll change it as you suggest.
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.
Fine will support both then
/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()?
No problems: parse_authority_info(<path to mimetype file|origin_url>)
works fine for me.
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.
I'm confused here. The user is adding a new Repo and installing packages
from it, so it won't be the preferred authority at that time, so how do
we handle this? Do you want to switch this New Repo to be your preferred
one, that is not what I thought we should do. If no repo is specified in
the MimeType file then that is an error and no packages will be installed.
We will always display to the user which Repo they are adding packages
from before they proceed, so this should be safe I would have thought.
- 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.
Agree - lets change it to a boolean field "registered" instead.
/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
Given that the user may always want to change the Name on their system
even if one is suggested by the authority I think the simplest thing
here is just to present the Add New Repository dialog to the user every
time, if the Authority is not registered on their system. I think that
seems reasonable behavior. When we get it up and running we can play
with it and see how it feels.
* 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.
Well it would be easy to save selections from the GUI to allow this type
of functionality to be implemented. What we could do is save them as a
.p5i file, one per repo, so then anyone could use this set of .p5i files
to install the set of packages again. We can talk about this when I'm
over in the US if you and Dan are on the West coast.
We'd just need another api to support this:
save_authority_info(<AuthorityInfo File>, <list of package names>,
<path to .p5i file>)
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
