Advanced Question Orbit Hangar - what approach for Orb 2016 vs 2010?

[ADSWNJ]

I'm assuming when the new beta is released, we will have four types of addons:

(1) Compatible with Orbiter 2010 but not Orbiter 2016.
(2) Compatible with Orbiter 2016 but not Orbiter 2010.
(3) Compatible with both Orbiter 2010 and 2016, with the same package.
(4) Compatible with both Orbiter 2010 and 2016, but with different distributions for each.

(I'm intentionally ignoring Orbiter 2006, as I assume people are largely not using this any more.)

Currently when uploading an addon, you get one choice of orbiter version only. I would like to see if the OH mods could implement a solution to handle each of the use-cases above in a way that's obvious to people downloading whether it's going to work or not.

My suggestion would be to have up to three optional uploads per distribution (comprising the addon file and the optional screenshot), and have, and have a series of tick-boxes per upload to tick for compatibility with orbiter versions (e.g. make it simple and just have: Orbiter 2006, Orbiter 2010, Orbiter 2016).

How would this work for a user: the search dialog would still work as today. Select the Orbiter version you want, then search, and you get any addon that has files for the selected version ticked.

How this would work for the developer: on the upload dialog, if you addon is compatible with multiple versions, then tick each version. If you need different uploads for different versions, then package each one and then upload with multiple add-on files with each one having a different combination of versions selected. (Ideally, you one one compatible version only per versions of Orbiter you are supporting, else the choice is indeterminant for O-H).


Other developers and O-H mods - what say you?

 

[Xyon]

From the code I've seen within OHM, the way this currently works is a one-to-one relationship between two database tables; one holding the Addon itself, and one holding the Orbiter version it corresponds to. I guess the mapping wasn't really designed with the idea that an addon could support multiple Orbiter versions, but it's something we've all seen is possible with some 2006-P1 addons still working in 2010-P1.

Adjusting this to a one-to-many relationship *could* be a bit tricky in the current schema, but it should be doable, and then a small amount of markup change in the upload form would permit binding to multiple supported versions of Orbiter.

The only really difficult part would be multiple file addons as you describe - I can't rationalise how I could accomplish that in the current system with the code and the database the way it is. That one needs a bit more thought from my side, but I like the concept; this reduces addon clutter, and makes linking to addons easier, since all the various versions can be in one page, and the appropriate copy downloaded by the user.

There are many features planned for the new version of OHM, but my time available to devote to it is sorely limited at the moment, so it's going to be a while before that's ready. I'm happy to consider amending the current site in the short term to improve the feature-set.

 

[ADSWNJ]

Thanks for the reply, Xyon. You need a third table then (e.g. Upload-Table) with a pointer to the Addon and to the version table, with the following columns:

* UploadID: masterkey
* AddonID: foreign key to addon table
* Orb version: foreign key to version table
* UploadFile: url or NULL
* ScreenshotFile: url or NULL


The search form then generates SQL similar to: SELECT * from addon a, upload u where a.addonID = u.addonID and u.version = '10080' etc...

For the update screen: change it to have three upload files and three screenshot files, with a drop-down for version. If NULL for both file and screenshot, then no entry needed into the upload table.

Make sense?

 

[Xyon]

I did some more thinking.

The best solution I can see is to change the addon table so that the filename becomes a one-to-many relationship, rather than being on the same table. This then allows one addon to reference multiple files, and each of those files in turn can hold a one-to-many mapping to the Orbiter Versions table to display its compatibility.

Make sense?

Edit: Reading your reply, I think you already got there on the implementation idea, since your post effectively describes what I just did. Fabulous!

 

[orb]

* Orb version: foreign key to version table

{...}

Make sense?

Well, no, there is only one version of orb existing here, unless you mean Orbiter.

 

[ADSWNJ]

All hail the Probe, and his faithful servant, Mr Orb!

Xyon, yup perfect. Still need a way to flag multiple orbiter versions, but having a multi-file structure in the file name is a good interim solution. Maybe make it a bit of XML describing the multiple downloads.

Let me know if you want an alpha tester.

 

[Xyon]

All hail the Probe, and his faithful servant, Mr Orb!

Xyon, yup perfect. Still need a way to flag multiple orbiter versions, but having a multi-file structure in the file name is a good interim solution. Maybe make it a bit of XML describing the multiple downloads.

Well, the addon itself wouldn't report a compatibility, we'd just inherit the Orbiter version list from all the child uploads and build a list based on that. So if an addon has three files each with one supported version, the addon lists those three versions as compatible, and you'll just get to pick which one you download.

Let me know if you want an alpha tester.

Alpha tester? I expect a fully documented pull request!

 

[ADSWNJ]

Ready when you are, Xyon!

 

[n72.75]

How did we do it with the 2006-2010 jump?

 

[Xyon]

How did we do it with the 2006-2010 jump?

I just added in the relevant versions to the list, but you can still only have one per addon, and one file per addon, which this work would improve.