Separating rave core from rave portal

[Erin Noe-Payne <er...@gmail.com>]

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?
Should we branch or push incremental changes into trunk?
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.

Re: Separating rave core from rave portal

[Chris Geer <ch...@cxtsoftware.com>]

On Fri, Mar 1, 2013 at 4:55 PM, Erin Noe-Payne <er...@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 <ch...@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.
> >
>

Re: Separating rave core from rave portal

[Erin Noe-Payne <er...@gmail.com>]

On Fri, Mar 1, 2013 at 6:10 PM, Matt Franklin <m....@gmail.com>wrote:

> On Fri, Mar 1, 2013 at 6:02 PM, Chris Geer <ch...@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.
>

Re: Separating rave core from rave portal

[Matt Franklin <m....@gmail.com>]

On Fri, Mar 1, 2013 at 6:02 PM, Chris Geer <ch...@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 <er...@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

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

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

Re: Separating rave core from rave portal

[Chris Geer <ch...@cxtsoftware.com>]

Erin, thanks for putting this together. My thoughts are in-line below.

On Fri, Mar 1, 2013 at 3:16 PM, Erin Noe-Payne <er...@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?