Oolite Bulletins

At present, there are some OXPs that have other OXPs within them - for dependency reasons usually. Others list them on their wiki page. In some cases, dependencies are optional, others are mandatory.

It seems that Perl, Python and TeX archives have produced ways to allow users to track dependencies and to avoid the issue of overstacking. I would therefore like to suggest COAN as an Oolite version of CPAN/CTAN/CPyAN, perhaps even stealing - err, re-using an existing module manager to allow users to install, verify and clean OXP collections.

This kind of thing is being worked on. Dizzy has a site called OXP Central which will be a central repository for OXPs with an OXP manager to check for latest versions etc.

Maybe you can give a link?

Zireael wrote:

Maybe you can give a link?

Unfortunately, it never came to fruition...

Zireael wrote:

Maybe you can give a link?

Sorry, but OXPCentral has not happened. Dizzy (the guy masterminding it) has disappeared off the scanners and no progress is possible without him as he controlled the Domain Name and Website.
If (as we all hope) Dizzy returns, then things might start moving again, but there is no sign of this happening.

Smivs wrote:

Zireael wrote:

Maybe you can give a link?

Sorry, but OXPCentral has not happened. Dizzy (the guy masterminding it) has disappeared off the scanners and no progress is possible without him as he controlled the Domain Name and Website.
If (as we all hope) Dizzy returns, then things might start moving again, but there is no sign of this happening.

Ok, who dropped the energy bomb in him?

Since there doesn't seem to be any active projects any more along these lines, I'm going to propose the setting up of COAN (Comprehensive Oolite Archive Network).

My first thought is that this should be modelled after CPAN for Perl, since the software for setting up CPAN-like archives, version checking and installing already exist. No need to re-invent any wheels, no need to do anything special for different platforms or different package management systems.

However, this won't work with OXPs that are distributed only by their originating site. The moment you have to download OXPs using multiple methods is the moment a distribution system is going to fall over.

However, this may be solvable. If each site provided an RSS/Atom feed from a well-known location on their site of the current versions of all OXPs provided and nothing else, with the URL of those OXPs, you have something a client could use to track OXPs and perform any desired updates.

Ideally, each site would have an automated means of updating the RSS feed every time the OXPs were updated. That shouldn't be too hard, but I'm willing to help there if anyone wants.

Once there's a standard-format of RSS announcement, it becomes possible to have an updater as part of Oolite. It also becomes possible for an archive network to be set up, albeit very literally on a publish/subscribe model, between sites that want to take part in such a network, provided there was an agreement to not replicate OXPs from sites that wanted to be sole suppliers.

Because RSS doesn't require any special software (it's just an XML-formatted list available via a web page), this shouldn't be hard to try.