roadmap...

[marijan milicevic <m....@onehippo.com>]

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

Re: roadmap...

[marijan milicevic <m....@onehippo.com>]

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:ate@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.milicevic@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
>>>
>>>
>>>
>>>
>>>
>

Re: roadmap...

[marijan milicevic <m....@onehippo.com>]

On 03/05/2012 01:52 PM, Franklin, Matthew B. wrote:
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@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.milicevic@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]


>> Regards,
>>
>> Ate
>>
>>
>>
>>
>>

RE: roadmap...

["Franklin, Matthew B." <mf...@mitre.org>]

>-----Original Message-----
>From: Ate Douma [mailto:ate@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.milicevic@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 

>
>Regards,
>
>Ate
>
>
>
>
>

Re: roadmap...

[Ate Douma <at...@douma.nu>]

On 03/02/2012 05:56 PM, Franklin, Matthew B. wrote:
>> -----Original Message-----
>> From: marijan milicevic [mailto:m.milicevic@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.

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).

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].

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.

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

Regards,

Ate

RE: roadmap...

["Franklin, Matthew B." <mf...@mitre.org>]

>-----Original Message-----
>From: marijan milicevic [mailto:m.milicevic@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.

>cheers
>marijan

Re: roadmap...

[marijan milicevic <m....@onehippo.com>]

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)
cheers
marijan