Niclas Hedhman wrote:
On Wednesday 09 January 2008 23:07, Richard S. Hall wrote:
Well, the original Felix project proposal was to implement the entire
spec and bring open source OSGi communities together under one project.
So, it seems to me that we should have our own and/or encouraging PAX to
join us.
<hat type="ops4j" >
The reason for the Pax projects in the first place was to provide a
development ground for OSGi platform independence. I have noticed that the
various implementations are re-doing the work, and interoperability is
second-hand to having your own implementation.
Pax puts a great deal of emphasize on interoperability, mostly by Pax Runner
easily starting any of the supported platforms, so we can check and
double-check that our bundles works on all.
Moving Pax, or parts thereof, to Felix is counter-productive to this goal, as
we practically alienate ourselves from the other groups. Given that OPS4J has
a "no barrier" policy for jumping in, helping out or starting new projects,
from my PoV it seems a lot more natural to move things out of Felix to Pax,
than the other way around ;o) (Not that it will ever happen.)
There is no attempt by any of our sub-projects to specifically tie
themselves to the Felix framework as far as I am aware. I think we want
all of our work to be interoperable where possible, so I think this is a
non-issue.
Apache has a barrier for obvious reasons, since there is some level of
commitment to having a project. Thus, it makes sense that projects are
started at places that have "no barriers" and then move to Apache when
they have started to solidify (generally via the incubator as you know).
Clearly, though, not everything needs to be at Felix, but I think our
goal was at least to target the specifications...
Of course, Apache License and all, we can't stop Felix from taking our work
and forking it to Felix's taste. Or as now is being discussed, trying to make
another implementation. But double-work is so wasteful...
Agreed, which is why I suggest that the PAX work join us.
-> richard
Mind you, we have plans to create a lot more TCK tests, to "weed out"
non-compliant implementations (such as the old org.ungoverned one) and get
clarifications from the Alliance where the spec is "unclear".
As for Rob's suggestion of a "strict" vs "extended" variant of the Http
Service, I think that is generally a good idea. But I think it is hard to
create a really "strict" one, since developers are always capable of finding
holes and digging into the less specified areas, and end up doing
coincidental programming. So I think it is somewhat wishful thinking that we
can reach that.
As mentioned, Pax Web would like to claim a "extended" title, as it now
supports deployment of WAR files, has full JSP support, filters, listeners
and so forth, and is at the same time Http Service spec compliant.
Feel free to draw your own conclusions.
</hat>
Cheers
