[DISCUSS] Plan for the Future

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

Now that things are starting to get to a usable state, I think we should start the discussion as to what a 1.0 release will (roughly) look like and what it will mean in terms of changes to the way we are currently working.  We are currently operating on what I would call a near-zero-constraints change policy that allows us to make any changes we like to the system, so long as everything works when we are done.  As more people build on Rave, this will become difficult to maintain.  I don't think we are quite there, yet, but we should have an understanding of what are the major features we want to have completed before stabilizing a release.    

>From a feature perspective, I think everything we have now should be solidified, but we also need a couple of new things that will be critical for anyone looking to use Rave in the beginning.  The list of new (major) features I thought would fit well into a 1.0 release are as follows:

1) Team pages:   A page with a group-owned set of widgets, OpenSocial Spaces 
2) Profile pages: A place to render information & widgets placed by the user
3) Rave as an OAuth Producer

Additionally, I think we really need to clean up and stabilize the object model and API, including tweaks to the current package structure to better support development and inclusion by downstream implementers.

If everyone agrees we should start working toward a 1.0 release, I recommend that we start adding the critical features to that version in JIRA and then picking them off as we do our monthly releases and moving them to the appropriate 0.x release.  

As for the post 1.0 changes to how we as a community work, I will let those of you who are much more experienced in running an Apache project suggest the process improvements needed to properly balance development and maintainability in the open source world.  

Thoughts?  I would especially like to hear from the community members who are building on Rave now as to whether or not the assumptions that prompted this e-mail hold true for them.

-Matt

Re: [DISCUSS] Plan for the Future

[Jasha Joachimsthal <j....@onehippo.com>]

On 10 January 2012 17:14, Franklin, Matthew B. <mf...@mitre.org> wrote:

> >-----Original Message-----
> >From: Martin Steinmann [mailto:martin@ezuce.com]
> >Sent: Monday, January 09, 2012 5:31 PM
> >To: rave-dev@incubator.apache.org
> >Subject: RE: [DISCUSS] Plan for the Future
> >
> >>
>
> >
> >     - Authentication takes place into another system and therefore
> signing
> >in invokes an SSO process.  1.0 release should have good support for SSO.
>
> The project uses Spring Security, which has multiple authentication
> strategies, including good SSO support.
>

We already have basic support for SSO depending on request headers. The
module adds a user to Rave when it's not already present. It doesn't update
the user data in Rave yet, but that is not hard to build. The SSO support
was built for a setup of Rave behind Shibboleth. You can find the
documentation on:
http://incubator.apache.org/rave/documentation/sso-login.html

What should be improved or added to satisfy your needs for SSO or does this
match your needs?

Jasha

RE: [DISCUSS] Plan for the Future

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

>-----Original Message-----
>From: Martin Steinmann [mailto:martin@ezuce.com]
>Sent: Monday, January 09, 2012 5:31 PM
>To: rave-dev@incubator.apache.org
>Subject: RE: [DISCUSS] Plan for the Future
>
>>
>>Subject: [DISCUSS] Plan for the Future
>>
>>Now that things are starting to get to a usable state, I think we should
>start the discussion as to what a 1.0 release will (roughly) look like and
>what it will mean in terms of changes to the way we are >currently working.
>We are currently operating on what I would call a near-zero-constraints
>change policy that allows us to make any changes we like to the system, so
>long as everything works when >we are done.  As more people build on Rave,
>this will become difficult to maintain.  I don't think we are quite there,
>yet, but we should have an understanding of what are the major features we
>>want to have completed before stabilizing a release.
>>
>>From a feature perspective, I think everything we have now should be
>solidified, but we also need a couple of new things that will be critical
>for anyone looking to use Rave in the beginning.  The list >of new (major)
>features I thought would fit well into a 1.0 release are as follows:
>>
>>1) Team pages:   A page with a group-owned set of widgets, OpenSocial
>Spaces
>>2) Profile pages: A place to render information & widgets placed by the
>user
>>3) Rave as an OAuth Producer
>>
>>Additionally, I think we really need to clean up and stabilize the object
>model and API, including tweaks to the current package structure to better
>support development and inclusion by downstream >implementers.
>>
>>If everyone agrees we should start working toward a 1.0 release, I
>recommend that we start adding the critical features to that version in JIRA
>and then picking them off as we do our monthly >releases and moving them
>to
>the appropriate 0.x release.
>>
>>As for the post 1.0 changes to how we as a community work, I will let those
>of you who are much more experienced in running an Apache project suggest
>the process improvements needed to >properly balance development and
>maintainability in the open source world.
>>
>>Thoughts?  I would especially like to hear from the community members
>who
>are building on Rave now as to whether or not the assumptions that
>prompted
>this e-mail hold true for them.
>>
>>-Matt
>
>We use Rave as a front-end dashboard for a SIP/XMPP based communications
>and
>collaboration application used by large enterprise and in the cloud.  We are
>an open source project ourselves and consider Rave upstream.  As we get
>deeper into it we expect to contribute back and participate more actively.
>Key points for a 1.0 release for us are:

Glad to hear it!  Thank you for providing your feedback.  We welcome your future contributions and  encourage your increased participation.

>
>a) Skinning needs to be well thought out and stable so that a skin developed
>for an earlier release can still be used through upgrades.  Layout needs to
>be flexible and finished.

I agree.  I know others in the community are really wanting to make some headway in this area soon.

>
>b) For us Rave is a user interface front-end, but it does not
>authoritatively manage users and accounts.  We depend on integration in the
>following areas:

+1 

>
>     - Authentication takes place into another system and therefore signing
>in invokes an SSO process.  1.0 release should have good support for SSO.

The project uses Spring Security, which has multiple authentication strategies, including good SSO support.

>     - User profile management is centralized and we need Rave to connect to
>a database (in our case MongoDB) to get / store profile information. 1.0
>release should allow different DBs.

Internally, we connect to LDAP, so we have similar concerns.  Do you have any specific suggestions for improving the SPIs or object model to support your use case?

>     - Login screen should be customizable as we do not allow account
>creation, and possibly other admin screens.  1.0 release should support UI
>customization.

+1

>        We would prefer not to have an admin section at all and let
>everything be configured via config files that can be created by another
>system.

Interesting thought.  So long as we provide clean management entry points, I think that you shouldn't have any issues building a custom solution to do this, but that highlights the need to have clean management entry points.

>     - OAuth to pull in gadgets from other catalogs.  1.0 release should
>allow different catalogs outside of Rave's own.

I think other community members have expressed the same concern.

>
>c) We also use Jetty instead of Tomcat and would like to see ongoing support
>for different app servers

+1

>
>--martin
>

RE: [DISCUSS] Plan for the Future

[Martin Steinmann <ma...@ezuce.com>]

>
>Subject: [DISCUSS] Plan for the Future
>
>Now that things are starting to get to a usable state, I think we should
start the discussion as to what a 1.0 release will (roughly) look like and
what it will mean in terms of changes to the way we are >currently working.
We are currently operating on what I would call a near-zero-constraints
change policy that allows us to make any changes we like to the system, so
long as everything works when >we are done.  As more people build on Rave,
this will become difficult to maintain.  I don't think we are quite there,
yet, but we should have an understanding of what are the major features we
>want to have completed before stabilizing a release.    
>
>From a feature perspective, I think everything we have now should be
solidified, but we also need a couple of new things that will be critical
for anyone looking to use Rave in the beginning.  The list >of new (major)
features I thought would fit well into a 1.0 release are as follows:
>
>1) Team pages:   A page with a group-owned set of widgets, OpenSocial
Spaces 
>2) Profile pages: A place to render information & widgets placed by the
user
>3) Rave as an OAuth Producer
>
>Additionally, I think we really need to clean up and stabilize the object
model and API, including tweaks to the current package structure to better
support development and inclusion by downstream >implementers.
>
>If everyone agrees we should start working toward a 1.0 release, I
recommend that we start adding the critical features to that version in JIRA
and then picking them off as we do our monthly >releases and moving them to
the appropriate 0.x release.  
>
>As for the post 1.0 changes to how we as a community work, I will let those
of you who are much more experienced in running an Apache project suggest
the process improvements needed to >properly balance development and
maintainability in the open source world.  
>
>Thoughts?  I would especially like to hear from the community members who
are building on Rave now as to whether or not the assumptions that prompted
this e-mail hold true for them.
>
>-Matt

We use Rave as a front-end dashboard for a SIP/XMPP based communications and
collaboration application used by large enterprise and in the cloud.  We are
an open source project ourselves and consider Rave upstream.  As we get
deeper into it we expect to contribute back and participate more actively.
Key points for a 1.0 release for us are:

a) Skinning needs to be well thought out and stable so that a skin developed
for an earlier release can still be used through upgrades.  Layout needs to
be flexible and finished.

b) For us Rave is a user interface front-end, but it does not
authoritatively manage users and accounts.  We depend on integration in the
following areas:

     - Authentication takes place into another system and therefore signing
in invokes an SSO process.  1.0 release should have good support for SSO.
     - User profile management is centralized and we need Rave to connect to
a database (in our case MongoDB) to get / store profile information. 1.0
release should allow different DBs.
     - Login screen should be customizable as we do not allow account
creation, and possibly other admin screens.  1.0 release should support UI
customization.
        We would prefer not to have an admin section at all and let
everything be configured via config files that can be created by another
system.
     - OAuth to pull in gadgets from other catalogs.  1.0 release should
allow different catalogs outside of Rave's own.

c) We also use Jetty instead of Tomcat and would like to see ongoing support
for different app servers

--martin