Oolite Bulletins

See the other thread about 'Live updates'. I have created a new namespace on the Wiki for development.

The first article is to start fleshing out what's needed for Oolite live updates - or Dynamic Oolite. I'm doing it in the Wiki since it gives us things like a change history etc. and is open, and you can read it and make suggestions etc. or tell me I'm full of crap (or whatever!)

See http://wiki.alioth.net/index.php/Develo ... mic_Oolite for the overview of the intended 'live update' system. It is a little vague at the moment - I need to explore the various libraries and think some more before making anything too concrete - because experience shows that if it involves networks it _must_ be done right or bad stuff happens.

Random thoughts:

• The versioning and dependency issues are related, and highlight what’s already an emerging problem: identifiers for OXPs. I’m fond of the Mac/Java reverse-DNS mechanism, in which good decentralised uniquing is easy. A root-level property list could specify the OXP’s identifer and version number, as well as the identifiers and minimum version numbers of dependencies. There was some other stuff I was thinking needed to be in a general plist (Info.plist? Manifest.plist?)… metadata like copyright string and a description would be nice [says the guy who wrote the Spotlight indexer].
• Preferably, OXPs which have an identifier should only be able to refer to their own resources and those in Oolite itself, unless they use some form of namespace syntax to access resources from a dependency (e.g. “Foo Part 2.oxp” might refer to a model from “Foo.oxp” using syntax like <key>model</key><string>com.example.foo:superdupership.dat</string>. It’d be nice if this could apply to mission variables too, to avoid conflicts. Ship roles are trickier; explicitly reccomending people to use an identifying prefix is probably as close as is possible there.
• I’m definitely for HTTP rather than a custom protocol. A libhttp wrapper which provides a similar interface to one of Cocoa’s HTTP methods would be nice, but adding a small technocally-redundant library to Mac-Oolite wouldn’t be a big deal.
• In addition to dependencies, scripts should be able to test for other OXPs and use bits of them if they’re available. Mmm, synergy effects.
• Hierarchies of key signing? (I.e. root certificate signs site certificate signs admin certificate signs OXP)
•  Development:Dynamic_Oolite_Protocol lists “A list of completed OXPs” as something that should be sent to the server to determine new OXP availability. I think that would be severely limiting; how would branching storylines work? It would be better if each OXP could set specific flags that are sent for this purpose, or “export” mission variables. This way you could set com.example.foo:joinedEvilBranch to get “Foo Evil Branch Missions.oxp”… although the name might not be the best. ;-)

Hierachies of signing are something that's easily supported by GPG - however, I've not really looked into implementation specifics of libgcrypt to see how it implements an interface to that kind of thing.

As for the protocol - your suggestion of an export variable - which can be anything - in the simple case it'd just be 'com.example.foo:complete=true' for mission commplete, and in the more complex case could indicate a branch taken (or whatever) sounds like a much better idea.

Synergy effects - that sounds like something for general implementation for OXPs rather than something specific for Dynamic Oolite

Ideally, it would be nice to implement it without having to massively change existing OXPs, but if it's needed it's needed (thinking specifically of namespaces - they aren't implemented at all at the moment because they've never been needed).

More thoughts:
* A metaserver listing all servers.
* Ability to change servers while docked.
* More powerful .oos'cripting (like mission screens allowing dynamic data, for server news maybe or hi-scores).

But maybe the focus should be put first in a simple in-game "download/remove/update/disable/enable OXPs" capability from a single server, where the player would be informed if an OXP works propery, is unfinished or in development. Then more complex features could be added later after something simple is working properly? Like, maybe this needs some milestones.

winston wrote:

Synergy effects - that sounds like something for general implementation for OXPs rather than something specific for Dynamic Oolite

Yeah, but this bit goes with the identifier concept.

As for the need to rewrite, I was thinking namespacing would only apply to OXPs which specify an identifier, existing OXPs essentially being in an anonymous namespace. Changes would only be needed to existing OXPs which reference content from other OXPs and are being updated for the server model.

Another random thought: the server-side logic used to select OXPs to activate really ought to work client-side, too, for when the user starts/loads a new game.