>-----Original Message----- >From: Martin Steinmann [mailto:[email protected]] >Sent: Monday, January 09, 2012 5:31 PM >To: [email protected] >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 >
