[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] R6 httpservice update

This would be brilliant if it could be accomplished.

I can image however that the logistics would be complex (I only guessing).

- Ray


On Fri, Mar 7, 2014 at 11:58 AM, <slewis@xxxxxxxxxxxxx> wrote:
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 <tjwatson@xxxxxxxxxx> 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 <raymond.auge@xxxxxxxxxxx>
>> To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
>> Date: 03/06/2014 02:19 PM
>> Subject: Re: [equinox-dev] R6 httpservice update
>> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>> ------------------------------
>>
>>
>>
>> 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
>> <*tjwatson@xxxxxxxxxx*<tjwatson@xxxxxxxxxx>>
>> wrote:
>>
>>
>> Â Â> From: *slewis@xxxxxxxxxxxxx* <slewis@xxxxxxxxxxxxx>
>>
>>
>> Â Â> >
>> Â Â> > 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
>> *equinox-dev@xxxxxxxxxxx* <equinox-dev@xxxxxxxxxxx>
>> *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
>> equinox-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
>>
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx
>> 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
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev



--
Raymond AugÃÂ(@rotty3000)
Senior Software Architect
Liferay, Inc.Â(@Liferay)