rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Franklin <m.ben.frank...@gmail.com>
Subject Re: Separating rave core from rave portal
Date Fri, 01 Mar 2013 23:10:54 GMT
On Fri, Mar 1, 2013 at 6:02 PM, Chris Geer <chris@cxtsoftware.com> wrote:
> Erin, thanks for putting this together. My thoughts are in-line below.
> On Fri, Mar 1, 2013 at 3:16 PM, Erin Noe-Payne <erin.noe.payne@gmail.com>wrote:
>> One of the major discussions at the ApacheCon Rave Hackathon was decoupling
>> the rave core from the rave portal. This is meant as a proposal / kick-off
>> discussion about where to divide the two.
>> Rave Core:
>> - Manages the data repository APIS.
>> - Javascript libraries to interact with apis, manage providers and provide
>> widget functionality.
>> - Does not implement views or controllers.
>> - Should be deployable independently of the portal.
>> Rave Portal:
>> - Web application implementing a portal on top of rave core.
>> - Provides a widget store, activity streams, and pages - the functionality
>> we currently see when we download rave.
>> Questions:
>> Are users / persons part of the rave core, or are they specific to the
>> portal?
> Users should be part of core, I'm not sure about Person. We might want to
> have a way to add modules to the core to extend the APIs independent of the
> portal.


>> Should we branch or push incremental changes into trunk?
> I think we should start incrementally. I'm going to create a first cut at
> the new api layer (independent of what is there now). Then we can see how
> we integrate with it. Maybe the new JS side talks with the new API as it's
> rolled out.


>> How much / little should the rave core do? On the server - anything more
>> than rest apis? On the client - make any assumptions about views / markup
>> structure or expect to be handed dom elements for rendering?
>> I'm especially interested in on Ate's take on this from the perspective of
>> being useful for Hippo & HMVC.
> Deployment question - is the core layer always deployed independently or do
> we bundle it with the portal?

I think we start with the assumption that the core is embedded in the
integrating webapp, in the case of the demo this becomes the portal.
In the event that someone wants to spin up a standalone core instance,
we should have a maven archetype that sets up a webapp around the

View raw message