[Auth]DotGNU Catalogue

[tali streit]

hey there everyone,

I typed this up quickly, and thought i might throw it to the group for 
discussion before making a proposal out of it.

Attachment is in HTML, hope this is ok.

-tali

Installation Catalogue

Version 0.0.1
Please provide feedback. Please note this document is by no means finished!
comments can be directed to tali streit (astreit at bigpond.net.au)

Preface

This paper discusses a mechanism for managing the installed DotGNU components on a system. It is intended to be referenced by members of the DotGNU mailing list.

A long discussed concept in software development is the idea of component reuse. Although we saw the introduction of reusable components in hardware, it never quite took off to the same degree in software. With the design of DotGNU, we once again have an opportunity to explore this area.

Various software pieces are referenced. A familiarity with these will aid in the understanding of this document. These include:
- Ximian's RedCarpet
- RedHat's Up2Date
- RedHat's RPM (and the various other packagers)
- Microsoft's Windows Update

Pluggable Components

Code Reuse: a particluar component is already in existance. Make use of it in your program. That is the theory.

Drawing an analogy to hardware, we wish to create reusable chips that can be combined in new and interesting circuit boards. Chips are our components and circuit boards are our programs.

To provide an example, think of the JPEG codec. Let us say that one has been developed and is called libJPEG or comJPEG or something. It is a component. GIMP, however, would make use of it. GIMP is a program.

The Installation Catalogue must therefore have the ability to manage the installation and removal of components, as well as programs.

As a user, we want to be able to download and install a particular application type (for example, The Instant Messenger). We would expect it to install all the required components.
As an adminsitrator we wish to be able to manage the installed components and upgrade/downgrade particular components.
As a programmer, we want the ability to publish components and programs. We also want the ability to require certain components in our programs.

Component Versioning

one of GNU/Linux's strength over a MS-Windows environment is the ability to have multiple versions of a library installed simultaneously. This is a desirable feature for numerous reasons, including backward compatibility requirements.

To facilitate this, we would allow for a program to reference a specific version number, or the latest version. In much the same way as GNU/Linux achieves this with symbolic linking.

Assuming that all DotGNU software is managed by the Installation Catalogue, we can keep track of components that are no longer required and remove them.

Auto-Request and component location

There is very little that is as frustrating, to a user, as installing a piece of
software and have it complain that it requires some cryptic component to be installed
properly first. This issue is less common with MS-Windows environments because of
their preference for all-encompassing distributions. This issue was addressed by
Ximian's RedCarpet by downloading the missing components.

Unlike the RedCarpet model, we do not wish to have a centralized provider. This means that required components may need to be downloaded from a third party server. To accomplish this we require not only a method for establishing authenticity, but also a means of locating the server to download from.

We therefore need a DNS (As in Domain Naming Service) style system of registering the download location for components and programs.

Program Locations

Similar to locating web pages, we would want to locate programs in reverse order:

gimp.painting.graphics.gpl
Where this would query the root server for GPL. Then Graphics/Painting/Gimp.

Although the example given sorts software primarily by licence (similar to .com vs .org), this is only one of many possibilities. It would be interesting what impact this would have on licencing though, wouldn't it :)

Component Locations

hmm. I suppose the same would apply here, except that the version number would be important.

0.8.81-pre1.comJPEG.codec.graphics.gpl
Please give your thoughts on this. The other question, of course, is the platform:
source.0.8.81-pre1.comJPEG.codec.graphics.gpl
i guess.

oh, and comJPEG.codec.graphics.gpl would simply be a link to the latest version. Perhaps we could also have stable.comJPEG.codec.graphics.gpl.

RSYNC is cool

if you have kernel 2.5.998, then upgrade to 2.5.999, you can pretty much assume that most of it will not have changed. One of the major problems with RedCarpet is that it does not provide differential downloads. Andrew Tridgell has written a very nice utility called rsync that handles this. rsync is cool.

One-Click Upgrade

Ever sit at your screen and think 'I have all this bandwidth and nothing to do with it'?? well now you don't have to any more - simply click your Upgrade button. It can be configured to do many different things, such as only get the latest stable versions, only check the software you use often...

but you could also let it upgrade every piece of software that you have to the latest versions. Why is this different to WindowsUpdate? because i mean EVERY peice of software. Not just one companies, but absolutely everything that is dotGNU related.

Just while i have the thought, if a component or program crashes, would be cool to have a button that checks to see if a later version has been released. :)

Information, Bug lists etc

there would need to be a lot of other information that could be looked up. Such as the change log, MD5 sums, a description of the package, credits, contact details and whatever else. This is a call out for the sorts of stuff we need. Please give your opinion!!

keeping inline with common practice:

gimp.painting.graphics.gpl/about

The Anatomy

It is my goal to get the catalogue running quite early in the project. I think that we should all use it to download the latest test Portable.Net etc.

To begin with it would be a set of command line utilities.

This may overlap with the authentication project in terms of locating a service. In our case we are looking for program and componet providers.

cmd liners

catlookup

lookup a name in the catalogue. to begin with we might just return the rsync compatible path. for example:

> catlookup catlookup.catalogue.dotgnu.gpl
dotgnu.org:/catalogue/catlookup
this is just off the top of my head - haven't thought about it too much. The real
one would use an RLS style system. Note though that the about information does not
necessarily have to live at the same place as the downloads.

catstat