[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-dev] Extensibility of the application model
|
I see it more under the aspect that I better postpone wide adoption of
this feature instead of providing a inferior alternative just for the
sake of speed. Especially as Platfrom has no good way to later change minds.
As you mention the platfororm should be "high quality", this (at least
for me) includes the best possible solution in terms of runtime,
dependencies and memory usage even if it costs more to archive this on
the platform side. Especially compared to todays usage, and the header
fulfills all of those, and much more complex features are already solved
in the OSGi world.
I'll try to add some tooling support for this as a blueprint, as I think
many usecases using (proprietary) plugin.xml can even be solved by
Manifest-Headers to.
And just because others are solving things in a non-optimal way don't
make it a valid reason to adopt such things.
Am 16.04.21 um 09:56 schrieb Mickael Istria:
On Fri, Apr 16, 2021 at 7:34 AM Christoph Läubrich
<laeubi@xxxxxxxxxxxxxx <mailto:laeubi@xxxxxxxxxxxxxx>> wrote:
> PDE to properly descibe/support this
I don't think this is part of PDE but should be part of the
"model-editor"/E4 support as it does not really has a meaning outside
this scope.
> by 4.20
as this feature is optional I think there is no need to rush as nothing
hurts if users are just aware/using it from by 4.20+ ...
I believe you see the change from a narrow angle and underestimate its
impact of this change in term of "development model" and strategies of
extensibility.
Extensibility of the Platform is its core value, the one that has
allowed it to be successful for such a long time. Success in term of
extensibility was achieved by making it high quality: with tools, with
documentation, with backward-compatibility and so on. An extensibility
approach must not be seen only from a runtime perspective, but also, and
probably more importantly from a developer experience perspective.
Here, the proposal to use a MANIFEST header is a new model, and until
it's not backed by solid documentation and tools, it will be a bad
quality way to deal with extensibility because of the story being
incomplete. I'm personally against adding into Platform runtime and its
maintenance duties some features that we don't plan to finish correctly.
For such a new extensibility model, correctness includes tools and
documentation. So without a commitment that tools and documentation will
be implemented and are part of a plan, I would rather see the runtime
part removed and its inclusion delayed.
For those reasons, I'm moving back to the idea that despite some
technical limitations and require slightly more boilerplate, using
Services would be better here: we already have a proper developer
experiences for services (via DS at least) with a way to document and
some tools to assist in its good usage. Sure, there is an impact on
bundle activation and classloading, but frankly, from Eclipse Platform
perspective and its typical use-cases, I don't think we have to see this
as a major con.
Even some "esoteric" use-cases of Platform (eg e(fx)clipse) seem to
prefer extra-activation via services over extra-MANIFEST attribute
I think that going to service/DS is a more pragmatic way forward, that
its value seems easier to leverage in other cases, and will cost much
less effort in building a good developer experience because almost
everything is already in place.
_______________________________________________
platform-dev mailing list
platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
