On 2017-07-22T11:34:07 +0000 elias vasylenko <eliasvasyle...@gmail.com> wrote:
> It still feels to me like you're putting the focus in the wrong place. The > problem in this example is still fundamentally being caused by a poorly > configured deployment containing unnecessary duplicates, so to me it sounds > like you're saying that you want the system to be forgiving to bad > configuration because user error is expected. Right. That is certainly half the problem. The other half of the problem is when two otherwise unrelated bundles try to register a provider with matching names. Obviously, this is a classic namespace management problem and isn't OSGi specific. > I can understand that, but if a user is doing things like installing > multiple superfluous versions of the same bundle, it's only to be expected > that their experience is not going to be perfect. Rather than trying to > work around users who don't know how to configure their installation and > organise their mods properly, isn't it better to think about how to make it > easier for them so they won't/can't make these mistakes in the first place? I agree completely. I suspect my outlook is somewhat... Pessimistic on this matter! I could imagine third parties that have no OSGi experience filling all of their bundles with Require-Bundle and then blaming me when the whole system works extremely poorly. There's a lot of venom directed at computer game authors in general (as games tend to be rushed and shipped broken), so I'm being proactive in terms of getting things right the first time and making it easy for people to do things correctly. > For example, you say that there is nothing stopping them from > (unnecessarily) installing the same bundle twice, but why? > > First of all, what actually constitutes the fundamental installation unit > of a mod? I assume it's either a special bundle (marked as a mod by some > particular capability/manifest header or contained file) or just a file > containing whatever meta-data describes the mod and a set of requirements > for the resolver? The terminology is a little muddy, because words like "mod" that make sense in terms of people making destructive changes to a traditional compiled native-code game with a fixed set of resources defined on release don't really make sense when used in terms of a generalized, extensible engine. Basically: I'm producing a core engine, and then I'm producing games (in parallel) using that engine. The core engine handles physics, rendering, networking, etc. Games are then loaded into this engine and are comprised of resources that define the levels, graphics, sounds, etc, and extra Java bytecode that defines game-specific in-game logic, scripting, etc. In this case, the games that are loaded in could be considered as "mods". In addition to this, it's obviously possible for people to write extensions to the core engine, and also to write extensions for specific games running on that engine (new levels, new creatures, etc). The word "mod" also applies to them, so let's stop using that term in order to reduce ambiguity! So to answer your question: I had intended for the fundamental installation unit to be the bundle. Presumably to deliver entire games, there would be specially marked bundles (perhaps using Bundle-Category) that would pull in a set of bundles as dependencies. The plan is to essentially give paying users access to OBRs containing the game's bundles, and set up some sort of system to allow users to publish their own bundles in OBRs. Games, extensions, etc, can declare dependencies on specific versions of APIs provided by the core engine, and those core parts of the engine can also be provided by OBRs. I'd also be handling updates to the core engine through this same mechanism. I have some unresolved problems with this, but that's for another thread and another day. :) I'm designing around fostering a strong community of people producing extra content for the game(s) right from the start. My intention is that the games I write for my engine don't have special status; they're installed, managed, uninstalled, etc, in exactly the same way that third party levels/extensions are. Third parties may also author complete games using the engine (in much the same way as people produce "total conversion" "mods" for games like Doom today). > Whatever the case, since you say there is a friendly UI I assume users are > not forced to manage naked bundles, right? So then they should only have to > deal with selecting "mods", with resolution/installation (and conflict > reporting) of dependency bundles managed transparently as a side-effect of > their mod selection. They are going to be managing naked bundles unless something major changes, but there would be dependency resolution and the like as you've described, so it presumably wouldn't be as granular and labour-intensive as that makes it sound. I'm hesitant to build another layer of packaging on top of OSGi bundles - I originally looked at OSGi because the packaging system I'd previously designed seemed to be a cheap imitation of OSGi bundles! I'm hoping individual bundles with standard metadata will be enough. > In this case I'm still convinced there's no point in worrying about > superfluous duplicates. Just disallow selecting different versions of the > same mod as a primary unit of installation, and trust that any duplicates > amongst the set of bundles resolved to satisfy the requirements of those > mods are only those duplicates which are necessary. In other words they > should avoid the problem described as according to the end of my previous > email. Perhaps you're right, yes. The UI itself could refuse to keep multiple versions of bundles with matching symbolic names. M
pgpoDulpWaTNc.pgp
Description: OpenPGP digital signature
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
