Hi Tom, Ray, others. FWIW, I've been trying to understand the situation WRT HttpService at Apache (Karaf, Felix)...and I just made a somewhat modest proposal [1].
To summarize this proposal...given that 1) there are likely lots of consumers of HttpService...many of them interested in the rfc-189 enhancements 2) the Apache-based community is in a similar situation to the EF community...of wanting to move to more recent/standards-compliant impls of HttpService 3) Both orgs are already using Jetty...and are looking to continue this My proposal: it would help to coordinate work on this across foundations/orgs, across corps, across projects...and thereby spread the necessary work. Further, it would/could reduce the individual 'stepping up' that's required to get to a strong standards-compliant implementation...perhaps more quickly. I would offer to propose/push this idea at EclipseCon, but cannot...so have to leave it as a bug in your respective ears. Scott [1] http://www.mail-archive.com/users%40felix.apache.org/msg15174.html > Awesome, > > This is a great response. > > Perhaps at EclipseCon I can demonstrate what I currently have to you Tom > as > we discussed (and perhaps others who are interested and in attendance). > > We can figure out if there is something here to work with. > > - Ray > > > On Thu, Mar 6, 2014 at 4:37 PM, Thomas Watson <[email protected]> wrote: > >> Hi Ray, >> >> I think your work in the "bridged" environment fits well with our >> existing >> implementation of the HttpService. Our implementation has a base bundle >> that implements the details of the HttpService, but the backing >> webcontainer implementation is left to something else (another bundle). >> For example, we provide a separate bundle that uses jetty to implement >> the >> backing container. This is what is used to serve up help in Eclipse. >> But >> our base http service implementation can also be embedded in a "bridged" >> scenario with a WAR using any hosting JEE server. >> >> I think it would be great to get your involvement in the project. If >> you >> have some proof of concept code we can certainly work towards nominating >> you as a committer for ongoing work to develop an R6 HttpService >> implementation within the Equinox project. >> >> Tom >> >> >> >> [image: Inactive hide details for Raymond Auge ---03/06/2014 02:19:24 >> PM---Hey guys, Some of you may be aware that I'm working on a >> ver]Raymond >> Auge ---03/06/2014 02:19:24 PM---Hey guys, Some of you may be aware that >> I'm working on a very prototypical (pre >> >> From: Raymond Auge <[email protected]> >> To: Equinox development mailing list <[email protected]>, >> Date: 03/06/2014 02:19 PM >> Subject: Re: [equinox-dev] R6 httpservice update >> Sent by: [email protected] >> ------------------------------ >> >> >> >> Hey guys, >> >> Some of you may be aware that I'm working on a very prototypical (pre >> alpha) impl of this. >> >> It will be open source regardless. But I've been given permission to >> make >> the suggestion of offering this to bootstrap or at least as a thought >> experiment for a collaboration of this work (the impl is pretty fresh >> and >> so is open to any change at all). We'd certainly benefit from all the >> experience here. >> >> Couple of caveats: >> >> 1) I'm not an Eclipse commiter but I already have to dedicate effort to >> both implementing and maintaining this long term (modularity being a key >> strategy for us) which could be of benefit to an sustained project under >> equinox. >> >> 2) Our impl is specifically geared to "bridged" environments. However, I >> think that it would be feasible to actually separate the part that's >> pure >> support of the OSGi side, from the part that either speaks to the >> bridge, >> or the embedded http server. Frankly that'd be ideal. >> >> Anyway, it's just a thought! >> >> - Ray >> >> >> On Thu, Mar 6, 2014 at 2:28 PM, Thomas Watson >> <*[email protected]*<[email protected]>> >> wrote: >> >> >> > From: *[email protected]* <[email protected]> >> >> >> > > >> > > There are no definite plans to implement the R6 httpservice >> > > implementation. >> > > But this is something I would like to see happen. >> > >> > FWIW...me/us too. For context: we have remote service providers >> that >> > depend upon HttpService, and it would be very nice for those and >> other >> > providers to use the R6 HttpService updates as soon as possible. >> > >> > We also have a pending contribution of a remote service provider >> that's >> > based upon/uses websockets [1] and would like to make that >> contribution >> > available to our consumers in Luna timeframe. >> >> I'm glad to hear there are folks interested, but we still need >> someone >> to drive the implementation. >> >> >> > >> > >In order for it to >> > > happen though we need an owner to step up to implement it. >> > >> > Perhaps this could be done by multiple committers collaborating >> > cross-project rather than (e.g.) one equinox committer. Perhaps >> also the >> > corporate members (others of which would probably also like to see >> > this...is my guess) could contribute support to such cross-project >> > collaboration. >> >> I was not intending to say this work has to be done by a single >> committer. But we do need someone with enough vested interest to >> drive >> this to completion. >> >> >> > >> > >I know Gunnar >> > > showed interest, but I don't know if he is in the position to >> drive the >> > > implementation. >> > >> > I don't know either. Unfortunately I cannot commit to drive it >> > myself...I've got enough on my own plate already. Although I >> can/would be >> > willing to contribute/collaborate. >> >> I'm willing to start a branch for the work, but I myself cannot spend >> lots of time on it either. After all I have to convince my employer >> to pay >> me for this work also ;-) >> >> >> > >> > >As for Luna, this cannot happen since the spec will not >> > > be >> > > done in time. >> > >> > Is that true? I was under the impression that the rfc-189 work >> would be >> > in R6. >> >> It is but that is R6 compendium. Compendium R6 is not going to be >> ready in time for Luna. I'm actually not sure when it will be final. >> I >> just sat through an EG meeting today and there is still significant >> work >> going on in the RFC. We have API freeze for Luna tomorrow (M6). >> >> >> > >> > >We would need to start in a branch that can be merged to >> > > master at an appropriate time for a release. >> > >> > Sure. Is this something that can/should be discussed at the >> > RT-PMC...and/or at upcoming EclipseCon? Seems to me likely that >> many (at >> > least) runtime projects likely use HttpService...and so I suspect >> you and >> > I are not alone in wanting to see it happen. >> > >> > Scott >> >> Sure we can discuss this at EclipseCon. >> >> Tom >> >> >> _______________________________________________ >> equinox-dev mailing list >> *[email protected]* <[email protected]> >> *https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev> >> >> >> >> >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect >> *Liferay, Inc.* <http://www.liferay.com/> (@Liferay) >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect > *Liferay, Inc.* <http://www.liferay.com> (@Liferay) > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
