rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Geer <ch...@cxtsoftware.com>
Subject Re: Separating rave core from rave portal
Date Sat, 02 Mar 2013 01:28:24 GMT
On Fri, Mar 1, 2013 at 4:55 PM, Erin Noe-Payne <erin.noe.payne@gmail.com>wrote:

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

Good question. Part of that will depend on the dependencies between the
entities. I think the core should contain everything to handle
widgets/pages at a minimum. If we decide Person is moved out of core we
need to decide if page sharing is based on Person or User.

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