-----Original Message-----
From: Ate Douma [mailto:[email protected]]
Sent: Sunday, March 04, 2012 9:34 PM
To: [email protected]
Subject: Re: roadmap...
On 03/02/2012 05:56 PM, Franklin, Matthew B. wrote:
-----Original Message-----
From: marijan milicevic [mailto:[email protected]]
Sent: Friday, March 02, 2012 11:34 AM
To: Rave developer list
Subject: Re: roadmap...
On 03/02/2012 05:30 PM, marijan milicevic wrote:
Hi all,
I was just checking Rave site but couldn't find any signs of
plans/roadmap/release planning...or is this intentional?
cheers
marijan
ok, forgive my ignorance...index page summarizes is (no dates/release
versions are mentioned though)
This, along with the architecture, is definitely something we need to
document. I had called for community needs in a 1.0 a while ago and am using
those requests, as well as others discussed on this list, to prepare a proposal
for a high-level, flexible roadmap that we can all agree to.
One of the things I was waiting for before proposing the roadmap is the
proposal that Ate is preparing. As indicated on a prior thread, I think that
proposal will have a great deal of impact on the roadmap.
I definitely think we need to start defining the general architecture of Rave in
the light of our initial and future roadmap goals.
So far we've build a nice set of features for Rave within a basic but only
initial setup of the application structure. And this was a good and agile
approach which we needed to get started, as a yet disparate group coming
from
different backgrounds. And to get something working quickly to validate and
show
the capabilities Rave *promises* to deliver.
I think we should now step back a little, and reconsider some of the,
sometimes
implicit, choices made so far.
To be honest, and in retrospect, in some area's I think we're now on the
wrong
track, or too much focused on 'getting it to work' without enough
consideration
of the (re)usability and usefulness for other users and downstream
developers.
+1.
Please note I'm *not* proposing or even suggesting we now should switch to
a
waterfall like design process. On the contrary: we should stick to agile and a
"release early - release often" approach. But we can use a bit more alignment
and reflection on our goals for the roadmap. Even if they are very diverse
(which is a GOOD thing).
+1. IMO, we will always make missteps and this is also a good thing as it
gives us the experience and context to do it better the next time. The key is
to revisit the choices.
For this I'd like to propose a set of architectural 'topics' which I think are
important to discuss, both separately and in relation to each other. I don't
want to elaborate on these in this email thread though, just point them out
briefly. For actual discussion of these we should use separate threads with an
appropriate subject prefix, like [discuss - persistence].
Good idea. I have been trying to think of a good mechanism to do this and was
going to wrap more than a few of the concerns you outlined below in the roadmap
proposal; but, this is a cleaner way to get community feedback and generate
discussion around each topic.
I'm also think we now finally should ask Infra for setting up a wiki (MoinMoin
being my preference, I'd rather not use Confluence). Mail threads are good
for
discussions but also easy to drift, and very time consuming to recap from.
A wiki provides an easy and light way to 'capture' new proposals or summarize
discussion threads otherwise drowned in the email archives.
If nobody objects, I propose to ask Infra for setting up wiki.apache.org/rave as
soon as Rave has graduated to TLP.
+1. I think each wiki page should have its own roadmap as well. I propose
that each topic below be broken into a set of steps to get from the current
state to the target and outline the transition in the wiki.
One thing I want to call out re the wiki is that we had previously decided that
documentation for the current release needs to be done in the CMS. I still
think this is a very good idea.
Apache Rave is a community driven project and it is up to the community to
decide what should get priority and in what way. But as an ASF project it also
is about a process driven by doers: those who actually chip in and contribute
should and will take the lead.
So, while I've got quite an extensive list of architectural topics I'd like to
be discussed, it is definitely not something I can take up on my own, nor
would
I want to. Nor do I think all can or should be treaded equal or even be of
interest to many of you.
Most importantly: if any of these, or any other topic, is of importance to
*you*, don't wait bringing it up. Definitely don't wait on me, or anyone else.
As Matt indicates above, and I myself mentioned before on other threads, I
*am*
working on some feature and architectural change proposals, and I intend to
present these ASAP. But it is not good when others are waiting on that...
So, that said, here comes 'my list'. Please chime in and extend, but use
separate threads when actually discussing them:
* [persistence] multiple persistence back-end support, SQL, noSQL, JCR,
mixed
* [shared data] sharing data between portal and providers
* [shared model] sharing data model between portal and providers
* [clustering] separate portal(s) and provider(s) nodes
* [widget-catalog(s)] external catalogs, shindig v.s. wookie or combined
* [security-management] person/user, groups/roles, OAuth, Identity, SSO
* [profile-management] pluggable and extendable user model and
controller(s)
* [w3c-opensocial] overlap, generalization, widget model
* [mashups] spaces, shared data, messaging, coordination, linking
* [feature-management] rave,shindig,wookie pluggable/customizable
services
* [services-api] exposing& integrating (custom) services generically
* [build-extensions] overlays, packaging, modularization
* [front-end customization] theming, scripting, client/server-side
* [page-model] page structure definition (not Rave Page but web page)
* [aggregation] page controller(s), single v.s. multiple/hierarchy controllers
* [navigation] url and page/component mapping, linking and management
* [content-services] dynamic web content and data services
* [dynamic-page-templates] pages, layouts, themes, etc. managed with
services
* [reusable controllers] pluggable components with customizable front-ends
* [enterprise-ui] user/role/group access rules, locked layouts, action controls
* [activitystrea.ms] feature support
* [embedded-experiences] feature support
* [runtime-management] site(s), mappings, content, services, features
* [context-mapping] dynamic mapping urls to context driven pages
* [context-experiences] inverse of embedded-experiences: Rave injected
contexts
* [context-services] dynamic context driven (callback) services
[administration] pluggable configuration and administration
[group areas] navigable team or group pages with shared widgets
