Skip to main content

[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.

Yeah.

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

My only comment about this is that if it's one thing that EF projects do
pretty well now, it's complex logistics [1].

Best of luck with getting it to happen at EclipseCon (and wherever).   If
help is needed/desired please let me know.

Scott

[1] https://wiki.eclipse.org/Luna/Simultaneous_Release_Plan

>
> - 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é* <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
>



Back to the top