rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erin Noe-Payne <erin.noe.pa...@gmail.com>
Subject Re: Separating rave core from rave portal
Date Fri, 01 Mar 2013 23:55:09 GMT
On Fri, Mar 1, 2013 at 6:10 PM, Matt Franklin <m.ben.franklin@gmail.com>wrote:

> 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.
>
> +1


+1 for extensible APIS. To phrase differently then, what models /
relationships do we have in rave now that we do not see core managing?
Friends, page sharing, page templates...widget comments, tags, ratings?


> >
> >
> >> 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.
> >
>
> +1
>

Yes. As the api rolls out it will be easy to integrate with JS api
seamlessly (in theory).


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message