felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sten Roger Sandvik <...@x3m.com>
Subject Re: Felix HttpService improvement...
Date Thu, 27 Aug 2009 22:24:47 GMT
Kind words :-) I know sling would benefit from this implementation. Working
on a OSGi project too that is in need for such a service. One http bundle
that fit's every deployment method makes the distribution a little easier
:-)

BR,
Sten Roger

On Fri, Aug 28, 2009 at 12:19 AM, Felix Meschberger <fmeschbe@gmail.com>wrote:

> Hi,
>
> Sorry for the delay ...
>
> I have looked at it and I am kind of impressed. This looks exactly like
> something which has been turning in my head for some months now, too...
>
> Good stuff and -- as Marcel said -- clearly structured. I would
> definitely welcome this as a contribution to Apache Felix
>
> .. and I could even imagine, that in Apache Sling we would strongly
> consider migrating to this, too (as you hinted in the issue ;-) ).
>
> Regards
> Felix
>
> Sten Roger Sandvik schrieb:
> > Now I'm back from vacation and has brushed up the code. I have submitted
> a
> > Jira task with the details (FELIX-1456). Since I really hate Jira as a
> patch
> > repository and I do not have commit rights I have uploaded the source and
> > binaries at a google hosted repository. It's two examples inside to show
> how
> > to use the bridged implementation. Tell me what you think :-)
> >
> > BR,
> > Sten Roger
> >
> > On Wed, Jul 29, 2009 at 6:36 PM, Sten Roger Sandvik <srs@x3m.com> wrote:
> >
> >> Great. I am on a vacation right now, but when I'm back I will make
> >> available the code and binaries so that others can play with it.
> >>
> >> // srs
> >>
> >>
> >> On Tue, Jul 28, 2009 at 4:39 PM, Richard S. Hall <heavy@ungoverned.org
> >wrote:
> >>
> >>> On 7/28/09 2:44 AM, Rob Walker wrote:
> >>>
> >>>> We're a big user of the current felix Jetty http.
> >>>>
> >>>> Would definitely welcome any improvement/enhancement - personally I'd
> >>>> like to see it as a parallel implementation initially, so we can look
> at
> >>>> both side by side. And then later, if/when everyone is happy and has
> moved
> >>>> across then we could look to deprecate the existing one.
> >>>>
> >>>> My motives are purely selfish here - we have a lot of live users on
> the
> >>>> current implementation, and have had a couple of issues in the past
> where
> >>>> changes broke these implementations. So it'd be good to be able to
> stage any
> >>>> migration.
> >>>>
> >>> Even if we replace the existing impl, the old binary and source
> releases
> >>> do not go away, so no one would be forced to upgrade before they were
> >>> ready...of course, if there is some irreconcilable incompatibility
> between
> >>> the two then we'd have an issue, but I doubt that would be the case
> since
> >>> they are supposed to be implementing the same spec.
> >>>
> >>> Well, it sounds like there is sufficient interest, so it would be great
> if
> >>> Sten could make it available for people to play with via JIRA.
> >>>
> >>> What do you think, Sten?
> >>>
> >>> -> richard
> >>>
> >>>
> >>>
> >>>> On the plus note - although our usage is quite basic, we do stick
> >>>> strictly to what OSGi exposes as the HttpService API layer and use no
> other
> >>>> features. So we make quite a good test site to ensure the fundamentals
> of
> >>>> the base API are working as per the spec.
> >>>>
> >>>> Regards
> >>>>
> >>>> -- Rob
> >>>>
> >>>>
> >>>>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message