streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Letourneau <>
Subject Re: ApacheCon Recap & Next Steps
Date Wed, 13 Mar 2013 18:15:58 GMT
Glad you all made it back in one piece.

On Wed, Mar 13, 2013 at 11:41 AM, Matt Franklin
<> wrote:
> For all of you who missed it, Craig gave a nice intro into what we are
> trying to accomplish with Streams at Apachecon [1].  At the conference
> there was a fair bit of interest and what seemed to me like potential
> alignment; however, there are some serious issues to discuss and work
> to resolution.  The issues I heard are as follows:
> 1) Everyone is interested, few are engaged.
>     There are quite a few people who could use this software, but
> aside from Jason, we really haven't seen much activity in development
> or architecture.
> 2) The current code is not easy to engage with
>     We need to lay out tutorials on how to get started and discuss
> general architecture and package structure

I'm not sure its the code so much as the project structure.  With
flexibility and highly componetized (read extensible) architecture
comes complexity.  If the vision is just being lightweight, OSGI can
go away and some of the modules can be merged.  I was imagining an
environment where hot-swapping implementations or adding new routes on
a live server would be desirable.  With just WAR, scalable is still
achievable (via messaging and reconfiguration), but that assumes one
deployment type rather than maintaining flexibility around it out of
the box. No strong opinion here, but it was fun to make it work for

> 3) We need processing pipelines for incoming and outgoing activities
>     How these pipelines are created, managed (workflow?), parallelized
> and augmented by custom components needs to be discussed

Camel can do all of this (create routes on the fly and send messages
to beans) - see registration classes in eip-messaging.  A custom
component just needs to grab the Camel context and implement the
appropriate interface.

> 4) We need to support some kind of persistence
>    Most people want to do ad-hoc querying rather than direct
> subscription notification (though both should be supported IMO), but
> we need persistence, indexes & a whole lot of thought to make this a
> reality

Should be straight forward to add a component that handles that
somewhere along the publishing pipeline.  A default subscriber without
any filters that pulls from the Q would work.

> 5) Dependencies need help
>    Someone brought up that all of our dependencies are versions old
> and need to be upgraded
> Anyone have any thoughts on these issues and how we as a community can
> move past them?  Did anyone else have other issues to add to the list?
> -Matt
> [1]:

View raw message