>-----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 > >Regards, > >Ate > > > > >
