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.) 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... 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 -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
