Re: [osgi-users] Possible mistake in Feature spec?

[Mark Raynsford <org.eclipse@xxxxxxxx>]

On 2022-05-27T12:30:52 +0200
Stefan Bischof <stbischof@xxxxxxxxxxx> wrote:

> Hello,
> 
> 
> your description of F-R-B is correct. Please feel free to open an PR to 
> the Spec that describes it in better that the existing description.

Got it, thanks. I might do this!

> ```
> Is there some way a Feature itself can define extra requirements or
> capabilities that I'm not seeing?
> ```
> 
> We had a point in the spec process where we had an Prototype of Req and 
> Cap of Features. But in the discussion we realized that currently there 
> are not enough valid use-cases to be sure to bake it into the Spec. Most 
> cases I had  end with the decisions that a Bundle holding the Req and 
> Cap would be the better way. Would be nice to discuss this with you here 
> - or better - in the next spec call! I Think David Bosschaert would be 
> also interested in hearing your use-cases.

I think my use case might be fairly unique, and I'm still undecided if
Features are actually what I should be using.

I'm building a commercial (but open source) computer game. It's a
passion project right now, and I'm waiting for a couple of JDK things to
land before I can advance (Project Loom, in particular), but I hope to
publish the game on Steam and the like when it's done.

A design intent from the start was to fully support third party
modifications. Most computer games nowadays either have people reverse
engineering them to provide mods (which is fragile, obviously), or they
expose a limited API such that the original game is a first class
citizen, and modifications are second class citizens.

My intention is to publish a somewhat generic game engine, and then
publish somewhat episodic content on top of that engine, installed via
a user-friendly launcher. Other people can also publish episodic
content, or additions to the game, through that same launcher. In
effect, game content that _I_ produce doesn't have special status over
game content that _someone else_ produces.

The game engine is exposed as a set of OSGi bundles loaded into a
pretty bare-bones Felix container, and the game content is represented
by a different set of OSGi bundles that get loaded in on top of that.

Where Features come into this picture is due to the NP-complete nature
of bundle resolution. I want to expose a large user-modifiable
directory (similar to Maven Central) where both myself and others
publish content. The contents of the directory will be somewhat of a
free-for-all (although with similar quality control measures and
group-based access restrictions as Maven Central). It _won't_ be the
kind of carefully curated repository that the OSGi resolver practically
requires in order to be able to resolve a set of requirements in a
reasonable timeframe.

The desired user experience is that users open a friendly GUI
application and pick Feature-like things from a catalog. These
Feature-like things are downloaded and then a Felix container is
started up containing the set of resolved bundles. My thinking is that
OSGi Features might serve this model well, because they (presumably)
make the resolution step easier given that the user is just combining a
few coarse-grained Features rather than trying to get the resolver to
pick out a few hundred bundles from a directory containing a nightmare
of thousands of probably-incompatible artifacts. :)

My thinking is that I would expose the "game engine" as a base
"platform" Feature, and then each episode of the game that I
would release would be its own Feature that depended on the game engine
Feature. Users could submit their own episodes that just use the game
engine, or they could submit bundles/Features that extend existing
episodes and/or add game engine features (lowercase 'f'!).

Does this sound like something Features could make practical?

-- 
Mark Raynsford | https://www.io7m.com