Re: roadmap...

[marijan milicevic]

On 03/05/2012 03:55 PM, marijan milicevic wrote:
On 03/05/2012 01:52 PM, Franklin, Matthew B. wrote:
-----Original Message-----
From: Ate Douma [mailto:a...@douma.nu]
Sent: Sunday, March 04, 2012 9:34 PM
To: rave-dev@incubator.apache.org
Subject: Re: roadmap...
On 03/02/2012 05:56 PM, Franklin, Matthew B. wrote:
-----Original Message-----
From: marijan milicevic [mailto:m.milice...@onehippo.com]
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

thx. this is indeed quite extensive list :)
cheers
marijan

PS:

One (small) thing that I don't see like to see is some kind of 
application monitoring/profiling
(e.g. being able to change logging level *runtime*)
*[application-monitoring]



hm..."I don't see like to see" is quite funny :) . That should read, 
either: I don't see
(or would like to see)..
/m



Regards,

Ate