the following is the "if i had lots of time scenario." in reality,
things will be implemented in the following order:
	1) url and browser-based upload and install (i.e., existing features)
	2) getting lists of available updates
	3) selecting and installing free updates
	4) automatically installing free updates
	5) presenting "for pay" packages with a url to the actual web
	   site. 	
	6) presenting payment info on the qube side.
	7) downloading and installing "for pay" packages.

Upgrades and Package Installation for Carmel

currently, cobalt provides the following browser-based package
installation methods:
	1) browser upload and install
	2) ftp upload to a specified directory with a browser-initiated
           installation
        3) url specified location

these features will be maintained in carmel. however, the current
update mechanism requires the administrator to play too active a role
in the process. in particular, the administrator must do all of the
following: 
	1) keep abreast of current updates and determine their
	   appropriateness. 
	2) "manually" apply each update
	3) apply the updates in the correct order 

the carmel update mechansism should minimize the need for such an
active role. to accomplish this, it will have a browser-configureable
mechanism for automated updates. through the interface, the
administrator will be able to configure the following: 
	1) email notification of new updates
	2) times to query for available updates
	3) automatic installation of updates
	4) location of update server
	5) selection of updates to install

benefits:
By providing an automated update process, we avoid many of the current
difficulties experienced with the current mechanism. namely,
admnistrators no longer need to play an active role in determining
whether or not their systems are up-to-date. Combined with an
avoidance of browser-specific issues, this results in both quicker
propagation of fixes and updates and lowered support overhead.


DETAILS

-- Client-Side --

Reporting of installed packages
the current format of files in /var/lib/cobalt consists of the
following:
NAME: <package name visible to ui>
URL: <url for further information>
<rpm name> <version> <release number> <md5sum>
 .
 .
 .

instead, package information will be stored in CCE using the special
Package class. here's what is in it:
	1) name
	2) version number
        3) enabled? 
	4) uninstallable? (default=true)
	5) the super-secret cobalt sort order so that we always show
	   up first.
        6) _Maintenance namespace:
	   a) uninstall handler
	   b) enable handler
	   c) disable handler
        7) _Description namespace:
	   a) short description (i18n tag)
	   b) long description (i18n tag)
	   c) context help
	   d) url for more info	
        8) _License namespace:
       	   a) start date
	   b) stop date
           c) price (with currency type)
	   d) key (dependent upon start/stop date, serial number, 
	           checksums of enable/disable/uninstall scripts and 
	           the program) -- need to think about this some more


Location of not-yet-installed packages
on the qube3, packages waiting to be installed will be placed in
/home/packages. as in the old-style way of doing things, packages will
be unpacked and installed from /home/tmp.

The package format

the package format will be enhanced to increase maintainability and
upgradeability. currently, it consists of a tar archive of rpms to
install, a packing list, and additional scripts to run. the new
package format will consist of an extensible header specifying useful
meta data and data segments so that the cobalt upgrade mechanism can
determine things like package size and applicability before
downloading the entire package.

NB: the cobalt upgrade mechanism will auto-detect the presence of the
new package header and try to revert to the old-style upgrade
mechanism if the older (tar) package header is detected.


UI features
The UI will consist of the following sections:
	1) Installed Packages
	2) Configuration 
	3) Available Packages (free stuff)
	4) Try, Rent, or Buy! (aka Shop!) (stuff that costs money)

The installed packages page
this will show the list of installed packages. the list will be
constructed dynamically by querying cce for all Package objects. If
the package is uninstallable, a checkbox will be available to select
the package will be clickable as well. similarly, if it's possible to
enable/disable a package, a checkbox will be available. for packages
that are either demos or for a limited time, you will be able to enter
a newer key someplace. 

The configuration page
The configuration page will have a selected list of channels to search
for updates. This list can be added to/removed from through
specification of urls or from a list of available channels.

In addition, the administrator can select the times at which to query
the update server for new packages and new channels. Finally, there
should be an "auto-update" checkbox on a per-channel basis that allows
admins to have updates automatically installed if no user intervention
is required. note: this is a big security hole if you don't choose
your channels correctly. i'll make sure that the connection isn't
allowed if the server's hostname doesn't match its certificate. The
configuration information will be kept in the System.SWUpdate
namespace. actual channel information will be kept in SWChannel
objects.

Each of the channels will provide information on whether or not a
package is free to allow the ui to correctly place them in the
appropriate section.


Available packages (free, so i like it)
The available packages page will have a list of selectable packages
that are available. In addition, there will be a "check now" button
that can be used to instantly refresh the page. each item in the list
of packages will have the package name, channel name, vendor name, and
the date of release. the admin can select the sort order based upon
any of these criteria. finally, url/upload fields will be available
for "manual" installs.


Try, Rent, or Buy! (this is kevin's favorite feature because it's not
	            free) 
demo, rental, and/or purchase capabilities are provided through the
same mechanism of having expiration dates associated with prices (demo
is a limited amount with no price, rental is similar with a price, and
purchase is forever with a price). it is up to the actual package to
provide hardcore expiration date/security handling. cce will try its
best, but if a root user mucks with cce, all bets are off. cce will
just run the "enable" script on the start date and the "disable"
script on the appointed expiration date. the periodic checking will
probably just plug into active monitor. alternatively, a program can
use the same api to check with cce for a valid key and disable itself
if the key is invalid. like the available packages page, there will be
a "check now" button that refreshes the page.


-- Server-Side --

we will run a web server here (suggested location: updates.cobalt.com)
specifically for updates. a template will be stored in the Channel
data on the qube and used to construct queries and responses for both
package listings and package retrieval. in most cases, a default
template should be acceptable. for example, to get information on
packages, the server would see the following:
	1) a submittal of the form
	   https://name/packages?ui=false&query=true&variable=value&...
        2) server queries its database and replies with a list of
	   packages and urls, their licensing type, and any associated
	   informational url that's appropriate.	
	3) if no info is needed to retrieve the package, the url will
	   point directly to the package.
	4) for a packages that need further info, the url will point
	   to a form to which information can be posted. the server
	   will verify the form submittal and return the actual
	   package data if everything is accepted. 
        5) as long as a license is valid, the server will allow the
	   same qube to download the package.

in addition to the non-ui interface, the server should have a regular
web interface that accepts the same information.


-- The automatic upgrade process --
here's what happens on from both the client and server side.

the following happens either in a cron job or when the admin hits the
"check now" button:
	1) qube opens an ssl connection to a designated channel. 
	2) qube sends a request to <channel>:/packages/? and
	   provides its serial number, product identifier, and current
	   os revision.
        3) the channel will reply with a list of packages that are
	   available for download. included in that list will be
	   information on whether or not the packages cost money, the
	   release date, the vendor, the retrieval url, and whether or
	   not it's a direct download.
        4) the client will discard any packages that are already
	   installed and store the rest of the information in cce.
	5) if the auto-update option is selected, the qube will
	   download and install any free package.
	6) for the cobalt channel, we will also return a list of new
	   channels that can be added. an email notification will be
	   made if there are new channels to select.

when the admin goes to the available packages page, the following will
happen: 
	7) the packages will be sorted into their respective licensing
	   type. 
	8) for the free packages, the admin can select multiple
	   packages for download. the qube will get these packages and
	   install them. in addition, the admin can add packages to
	   the list by specifying urls/desktop uploads.
        9) if the package is not free, you'll get a pop-up page where
	   you can enter the following information:
		a) demo -- just enter some optional, but useful
	                   customer profile info. 
	                   you'll get a demo key installed with the
	                   package. the admin will get an email when
	                   the demo key is about to expire.

	        b) rent/buy -- same info but with credit card stuff as
	                       well! if rental, the admin
	                       will get email a certain time before
	                       automatic debits will be made. the
	                       server's backend database will need to
	                       make sure that double-billing
	                       situations don't occur. 

-a
