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