Linguofreak
Well-known member
Orbiter has a fairly broad range of addons meant to assist in the development of other addons, such as Velcro and UMMU. The problem is that many of these addons can't be used together. For example, Velcro requires that a Velcro stage use the line "Module = Velcro" in its config file, giving no means that I'm aware of for adding Velcro functionality to a ship using a custom module. Meanwhile, UMMU requires that vessel using it use a custom module that links to the UMMU module. As a result, the two can't be used in the same vessel.
Therefore, I would like to propose the establishment of a set of standard modules, interoperable with one another, that implement important functionalities not provided by Orbiter itself, such as staging management (as currently provided by Velcro), cargo management (UCGO), and UMMU type functionality, as well as a means of allowing new functionality-providing addons to ensure interoperability with the aforementioned set of standard modules (such as by means of a wrapper module that functionality-providing modules, including the standard set, can link to). Together, these modules would expose an interface to be known as the "Orbiter Community API", or OCAPI.
Desirable features of OCAPI:
1) Complete interoperability: A custom module of a given type (vessel, planet, MFD, etc.) should be able to link to any OCAPI module, or any combination of OCAPI modules, appropriate for that type, and use the complete functionality of the module(s) it links to: For example, if a vessel module links to an OCAPI module providing cargo management functionality, it should be able to link to an OCAPI module providing staging functionality. Linking to and using the full functionality of either module should not restrict the functionality in the other module that the vessel can use, unless a combination of functionalities would be impossible in real life (such as some detail of staging restricting what kinds of cargoes a vessel could realistically carry).
2) Accessibility to config-only addons: As much as possible of an OCAPI module's functionality should be made available through config files, probably with the help of wrapper modules (vessels using OCAPI features might use "Module = OCAPIVessel", for instance, and then have a "OCAPIModules = X,Y,Z" line to specify needed OCAPI modules).
3) Use of existing code as much as possible: Where a set of functionality is implemented by an existing addon that is already seen as more or less a standard, that addon should be incorporated into OCAPI if the source is publicly available or if the author is willing to spend the time himself to modify it to be part of OCAPI, otherwise, if technical and licensing considerations allow, it should be wrapped by OCAPI. A new module should be written to reimplement existing functionality only as a last resort if no other means of providing that functionality in a manner that interoperates with OCAPI exists.
There may, however, be a few situations where it is desirable to break this rule: For example, there are MFDs that provide means of transferring fuel between vessels, but it would probably good to have a vessel-oriented, rather than MFD-oriented means of doing fuel transfers, so that vessels can specify what fuel types they carry for different tanks, what (if any) fueling adapters they have on different docking ports, what transfer rates they can provide or accept fuel at, etc. It might still be good to have an MFD that provides an interface to this functionality, but the "standard" fuel transfer MFD should simply be a front-end to the vessel-based fuel transfer API, rather than transferring fuel itself.
4)Source code and licensing: It is generally desirable that OCAPI modules be open source, to increase the [ame="http://en.wikipedia.org/wiki/Bus_factor"]bus factor[/ame] of OCAPI so that a single developer disappearing, followed by a new Orbiter version breaking an OCAPI module he maintained, does not cause that modules functionality to become unavailable. It is also desirable that modules not carry any GPL-style linking restrictions, so that addon developers aren't constrained in their choice of license by the license on an OCAPI module they want to use (which is to say, LGPL or BSD would be preferable to the GPL). It may also be good for the licensing terms for OCAPI modules to allow Martin to incorporate those modules into Orbiter if he wishes.
5)A standard distribution: Any developer should be able to make a functionality providing addon that interoperates with OCAPI and distribute it as they wish, but it is desirable for there to be a core set of OCAPI modules that have been vetted for quality and verified to interoperate that are distributed together. All OCAPI modules in the standard distribution should adhere to the above 4 points as much as possible, with certain exceptions: e.g, for modules that already exist to be incorporated into the standard OCAPI distribution, (4) might have to be relaxed, as I'm not sure how willing the developers of those modules would be to relicense their modules for incorporation into OCAPI, and I don't really desire to push them very hard to do so. For modules written specifically for OCAPI, on the other hand, it would probably be good to say they have to adhere to (4) to be included in the standard distribution.
6) List of desirable functionalities: Below I'll list some functionalities that might benefit from a standardized implementation through OCAPI, with existing modules (if any) that provide that functionality in parentheses. I'll edit this post to include other functionalities as I think of them. Feel free to list other functionalities that you think would be good to standardize in OCAPI:
Fuel transfer / fuel types
Crew and EVA management (UMMU)
Cargo management (UCGO)
Staging (Velcro*)
A means of specifying ephemerides/orbital perturbations in planetary config files
Intermodule communication (Enjo's new ModuleMessaging SDK)
*The Velcro documentation says that the standard staging implementation for Orbiter is Multistage, but as far as I understand, Vinka is MIA and Sputnik is not, which means that the bus factor for multistage is 0, while Velcro still has a non-zero bus factor (AFAIK, the Velcro bus factor is 1). Therefore, Velcro is a preferable standard to Multistage.
7) An [ame="http://en.wikipedia.org/wiki/Okapi"]okapi[/ame] for a mascot?
This is only a proposal, and OCAPI doesn't have to look exactly as I've portrayed it here (nor does it necessarily have to be called OCAPI, and if interest is low enough, it doesn't have to exist, though I think it would be massively helpful). Therefore, feedback would be much appreciated.
If you're a general addon developer, would you like to see something like OCAPI? Do you have an addon I did not list above that you think might be a good candidate for inclusion in OCAPI?
If you're a developer for one of the modules I've listed here as a candidate for incorporation into OCAPI, are you interested in participating? Do you anticipate licensing issues?
Comments? Questions? Snide remarks?
Therefore, I would like to propose the establishment of a set of standard modules, interoperable with one another, that implement important functionalities not provided by Orbiter itself, such as staging management (as currently provided by Velcro), cargo management (UCGO), and UMMU type functionality, as well as a means of allowing new functionality-providing addons to ensure interoperability with the aforementioned set of standard modules (such as by means of a wrapper module that functionality-providing modules, including the standard set, can link to). Together, these modules would expose an interface to be known as the "Orbiter Community API", or OCAPI.
Desirable features of OCAPI:
1) Complete interoperability: A custom module of a given type (vessel, planet, MFD, etc.) should be able to link to any OCAPI module, or any combination of OCAPI modules, appropriate for that type, and use the complete functionality of the module(s) it links to: For example, if a vessel module links to an OCAPI module providing cargo management functionality, it should be able to link to an OCAPI module providing staging functionality. Linking to and using the full functionality of either module should not restrict the functionality in the other module that the vessel can use, unless a combination of functionalities would be impossible in real life (such as some detail of staging restricting what kinds of cargoes a vessel could realistically carry).
2) Accessibility to config-only addons: As much as possible of an OCAPI module's functionality should be made available through config files, probably with the help of wrapper modules (vessels using OCAPI features might use "Module = OCAPIVessel", for instance, and then have a "OCAPIModules = X,Y,Z" line to specify needed OCAPI modules).
3) Use of existing code as much as possible: Where a set of functionality is implemented by an existing addon that is already seen as more or less a standard, that addon should be incorporated into OCAPI if the source is publicly available or if the author is willing to spend the time himself to modify it to be part of OCAPI, otherwise, if technical and licensing considerations allow, it should be wrapped by OCAPI. A new module should be written to reimplement existing functionality only as a last resort if no other means of providing that functionality in a manner that interoperates with OCAPI exists.
There may, however, be a few situations where it is desirable to break this rule: For example, there are MFDs that provide means of transferring fuel between vessels, but it would probably good to have a vessel-oriented, rather than MFD-oriented means of doing fuel transfers, so that vessels can specify what fuel types they carry for different tanks, what (if any) fueling adapters they have on different docking ports, what transfer rates they can provide or accept fuel at, etc. It might still be good to have an MFD that provides an interface to this functionality, but the "standard" fuel transfer MFD should simply be a front-end to the vessel-based fuel transfer API, rather than transferring fuel itself.
4)Source code and licensing: It is generally desirable that OCAPI modules be open source, to increase the [ame="http://en.wikipedia.org/wiki/Bus_factor"]bus factor[/ame] of OCAPI so that a single developer disappearing, followed by a new Orbiter version breaking an OCAPI module he maintained, does not cause that modules functionality to become unavailable. It is also desirable that modules not carry any GPL-style linking restrictions, so that addon developers aren't constrained in their choice of license by the license on an OCAPI module they want to use (which is to say, LGPL or BSD would be preferable to the GPL). It may also be good for the licensing terms for OCAPI modules to allow Martin to incorporate those modules into Orbiter if he wishes.
5)A standard distribution: Any developer should be able to make a functionality providing addon that interoperates with OCAPI and distribute it as they wish, but it is desirable for there to be a core set of OCAPI modules that have been vetted for quality and verified to interoperate that are distributed together. All OCAPI modules in the standard distribution should adhere to the above 4 points as much as possible, with certain exceptions: e.g, for modules that already exist to be incorporated into the standard OCAPI distribution, (4) might have to be relaxed, as I'm not sure how willing the developers of those modules would be to relicense their modules for incorporation into OCAPI, and I don't really desire to push them very hard to do so. For modules written specifically for OCAPI, on the other hand, it would probably be good to say they have to adhere to (4) to be included in the standard distribution.
6) List of desirable functionalities: Below I'll list some functionalities that might benefit from a standardized implementation through OCAPI, with existing modules (if any) that provide that functionality in parentheses. I'll edit this post to include other functionalities as I think of them. Feel free to list other functionalities that you think would be good to standardize in OCAPI:
Fuel transfer / fuel types
Crew and EVA management (UMMU)
Cargo management (UCGO)
Staging (Velcro*)
A means of specifying ephemerides/orbital perturbations in planetary config files
Intermodule communication (Enjo's new ModuleMessaging SDK)
*The Velcro documentation says that the standard staging implementation for Orbiter is Multistage, but as far as I understand, Vinka is MIA and Sputnik is not, which means that the bus factor for multistage is 0, while Velcro still has a non-zero bus factor (AFAIK, the Velcro bus factor is 1). Therefore, Velcro is a preferable standard to Multistage.
7) An [ame="http://en.wikipedia.org/wiki/Okapi"]okapi[/ame] for a mascot?
This is only a proposal, and OCAPI doesn't have to look exactly as I've portrayed it here (nor does it necessarily have to be called OCAPI, and if interest is low enough, it doesn't have to exist, though I think it would be massively helpful). Therefore, feedback would be much appreciated.
If you're a general addon developer, would you like to see something like OCAPI? Do you have an addon I did not list above that you think might be a good candidate for inclusion in OCAPI?
If you're a developer for one of the modules I've listed here as a candidate for incorporation into OCAPI, are you interested in participating? Do you anticipate licensing issues?
Comments? Questions? Snide remarks?
