You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Marlon Pierce <mp...@cs.indiana.edu> on 2011/04/05 16:47:09 UTC
Bootstrapping RAVE code
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Based on previous emails, I think we had consensus on the following points: we will start a new code base, and we'll base it on SpringMVC framework. Unfortunately that's as far as we've gotten.
I'd like to suggest the following: let's create a skeleton project with Spring + Shindig and start fleshing it out. This will be a throw-away so we will want to tag it appropriately. This should hopefully initiate more detailed design discussions over email, etc. I think this will be easier if we have some code to comment on. I realize that there is the danger that the "throw away" version doesn't actually get thrown away, but I think we can accept this risk.
Raminder, Gerald, and I are Spring novices, so we need a volunteer from Mitre or Surfnet to design the skeleton. I promise we'll add to the framework as soon as it is created.
What does everyone think? I'm open to other plans and just want to see things start moving.
Marlon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNmyttAAoJEEfVXEODPFID1nsH/ArayUOLnfu9UEH5CoR5iVwH
njWgUnO2vd0GoCAw/94hSiFPQaCXBuoCs7eT1xS4ezpn4hljGwZFI2K5/73fb0S2
MDxVUqgTBgcZLlI6fnN9EAsinLCugr6LrO3PRM9IakKutoYJFczOsasQ8JDyYPrh
63GYiLgDKuFGcbHoh20sTfPnVRoXklLbdH131Z+TIEBFvVuQlGigdEPXhrauAvvg
OmyPuDhSg+fLtj9mQkhBENPG5fHgvE6/LdCPg1EJi/OUTw7/OJzY2euMmDHsYBTG
nmdAKlnnWQxwPXoGvkzGWMoFcLXOWr+7TqSPaGTZ+4F1N9FRpUxGAVozrw550Jc=
=1dJa
-----END PGP SIGNATURE-----
Re: Bootstrapping RAVE code
Posted by Scott Wilson <sc...@gmail.com>.
On 5 Apr 2011, at 16:19, Franklin, Matthew B. wrote:
> Thanks Marlon. I was planning on kicking up the discussion today also :)
>
> Personally, I don't think that starting with a throwaway is quite the
> right route. I agree that we are stalled on the next steps, and that it
> always helps to have code to comment on; but, we already have 2 (soon 3)
> codebases that we can use as drivers for our discussion.
>
> In my mind, the big question is what does the "10,000m" architecture
> (sorry to use a cliché) look like. Not specifics as to how each detailed
> component will work, but what are the general organization principles we
> need to follow. For instance, you mentioned creating a skeleton that
> includes Shindig. In our experience, the more loosely coupled the
> application is to Shindig the better.
+1
Rave's core function is the management of the "things formerly known as portlets". Shindig is just the highest-priority component to integrate to provide them.
> These discussions are more about
> ensuring consistency and providing developers some heuristic to follow as
> we break out and implement individual features.
>
> I definitely don't mean to imply that we need to architect or design the
> whole thing up front. That is an equally bad, if not worse, approach than
> throw away in my opinion.
Indeed, I think there can be a useful middle ground.
> That being said, when it comes to putting together the project skeleton,
> Tony, Jesse or I would be more than happy to take a first run.
Great, I suggest you go ahead, and then write something really brief explaining what each of the pieces are for.
> So back to where do we start? I think the first thing we do is take the
> feature list from the wiki and discuss how we want to implement the
> highest priority one, using the existing codebases as reference for the
> discussion.
Sounds good to me.
>
> -Matt
>
> On 4/5/11 10:47 AM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Based on previous emails, I think we had consensus on the following
>> points: we will start a new code base, and we'll base it on SpringMVC
>> framework. Unfortunately that's as far as we've gotten.
>>
>> I'd like to suggest the following: let's create a skeleton project with
>> Spring + Shindig and start fleshing it out. This will be a throw-away so
>> we will want to tag it appropriately. This should hopefully initiate
>> more detailed design discussions over email, etc. I think this will be
>> easier if we have some code to comment on. I realize that there is the
>> danger that the "throw away" version doesn't actually get thrown away,
>> but I think we can accept this risk.
>>
>> Raminder, Gerald, and I are Spring novices, so we need a volunteer from
>> Mitre or Surfnet to design the skeleton. I promise we'll add to the
>> framework as soon as it is created.
>>
>>
>> What does everyone think? I'm open to other plans and just want to see
>> things start moving.
>>
>>
>>
>> Marlon
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iQEcBAEBAgAGBQJNmyttAAoJEEfVXEODPFID1nsH/ArayUOLnfu9UEH5CoR5iVwH
>> njWgUnO2vd0GoCAw/94hSiFPQaCXBuoCs7eT1xS4ezpn4hljGwZFI2K5/73fb0S2
>> MDxVUqgTBgcZLlI6fnN9EAsinLCugr6LrO3PRM9IakKutoYJFczOsasQ8JDyYPrh
>> 63GYiLgDKuFGcbHoh20sTfPnVRoXklLbdH131Z+TIEBFvVuQlGigdEPXhrauAvvg
>> OmyPuDhSg+fLtj9mQkhBENPG5fHgvE6/LdCPg1EJi/OUTw7/OJzY2euMmDHsYBTG
>> nmdAKlnnWQxwPXoGvkzGWMoFcLXOWr+7TqSPaGTZ+4F1N9FRpUxGAVozrw550Jc=
>> =1dJa
>> -----END PGP SIGNATURE-----
>
Re: Bootstrapping RAVE code
Posted by Ate Douma <at...@douma.nu>.
On 04/06/2011 03:11 PM, Scott Wilson wrote:
> On 6 Apr 2011, at 13:56, Ross Gardler wrote:
>
>> On 06/04/2011 13:44, Franklin, Matthew B. wrote:
>>> On 4/5/11 1:39 PM, "Scott Wilson"<sc...@gmail.com> wrote:
>>
>> ...
>>
>>> In my mind, widget is the most generic and well understood term for all
>>> types of gadgets/widgets.
>>
>> A widget [1] is not a gadget [2] (that's only one of quite a few possible interpretations). In Apache Wookie this becomes a real problem as it can host both widgets and gadgets transparently for the end user. We just about get away with it in Wookie since it is not an end user tool, but Rave is.
>>
>>> What about keeping widget as the name rather
>>> than introducing a new term?
>>
>> I'd be OK with that, but not OK with Gadget (although not -1)
>>
>> However, today Gadget is the more recognised term, Perhaps Scott was just trying to be polite and not force the Wookie related motivations - then again maybe I'm completely wrong and Scott has another reason for his suggestion.
>
> Well, more just trying to keep the distinction clear between "the thing Rave manages" and "the thing Shindig provides (OpenSocial Gadgets) or Wookie provides (W3C Widgets)". So Rave internally needs the concept of the object it manages on each page for which is gets the content from elsewhere.
>
> If nothing else the class name for these things in Java needs to make some sort of sense and connect with the user documentation "how to add a [thing] to you Rave page" etc.
>
> And usually in a CMS or portal these are indeed called "widgets" (or portlets). I'm happy with "widget" or "Rave widget" (note the lowercase 'w') as it does feel a little more neutral than "Gadget". However I'm pretty easy either way.
>
> (But its still mildly confusing, hence my slightly tongue-in-cheek suggestion of "ravelet" :-)
>
My preference also goes to Rave Widgets (with captital W, to indicate they
represent a specific Rave based model/definition, which it will).
Gadgets are probably more recognized, but especially because they are
strongly/only associated with OpenSocial and/or Google.
Widgets are less "concrete" and (mis)used in many more different contexts. That
makes them less explicit but also more generic as general term.
Besides W3C Widgets, OpenAjax also uses Widgets and (now dead) SocialSite also
used Widgets.
I see no problem in adding another type to the mix: Rave Widgets :)
Ate
>
>>
>> Ross
>>
>>
>> [1] http://www.w3.org/TR/widgets/
>> [2] http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadgets-API-Specification.html
>
Re: Bootstrapping RAVE code
Posted by Scott Wilson <sc...@gmail.com>.
On 6 Apr 2011, at 13:56, Ross Gardler wrote:
> On 06/04/2011 13:44, Franklin, Matthew B. wrote:
>> On 4/5/11 1:39 PM, "Scott Wilson"<sc...@gmail.com> wrote:
>
> ...
>
>> In my mind, widget is the most generic and well understood term for all
>> types of gadgets/widgets.
>
> A widget [1] is not a gadget [2] (that's only one of quite a few possible interpretations). In Apache Wookie this becomes a real problem as it can host both widgets and gadgets transparently for the end user. We just about get away with it in Wookie since it is not an end user tool, but Rave is.
>
> > What about keeping widget as the name rather
> > than introducing a new term?
>
> I'd be OK with that, but not OK with Gadget (although not -1)
>
> However, today Gadget is the more recognised term, Perhaps Scott was just trying to be polite and not force the Wookie related motivations - then again maybe I'm completely wrong and Scott has another reason for his suggestion.
Well, more just trying to keep the distinction clear between "the thing Rave manages" and "the thing Shindig provides (OpenSocial Gadgets) or Wookie provides (W3C Widgets)". So Rave internally needs the concept of the object it manages on each page for which is gets the content from elsewhere.
If nothing else the class name for these things in Java needs to make some sort of sense and connect with the user documentation "how to add a [thing] to you Rave page" etc.
And usually in a CMS or portal these are indeed called "widgets" (or portlets). I'm happy with "widget" or "Rave widget" (note the lowercase 'w') as it does feel a little more neutral than "Gadget". However I'm pretty easy either way.
(But its still mildly confusing, hence my slightly tongue-in-cheek suggestion of "ravelet" :-)
>
> Ross
>
>
> [1] http://www.w3.org/TR/widgets/
> [2] http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadgets-API-Specification.html
Re: Bootstrapping RAVE code
Posted by Ross Gardler <rg...@apache.org>.
On 06/04/2011 13:44, Franklin, Matthew B. wrote:
> On 4/5/11 1:39 PM, "Scott Wilson"<sc...@gmail.com> wrote:
...
> In my mind, widget is the most generic and well understood term for all
> types of gadgets/widgets.
A widget [1] is not a gadget [2] (that's only one of quite a few
possible interpretations). In Apache Wookie this becomes a real problem
as it can host both widgets and gadgets transparently for the end user.
We just about get away with it in Wookie since it is not an end user
tool, but Rave is.
> What about keeping widget as the name rather
> than introducing a new term?
I'd be OK with that, but not OK with Gadget (although not -1)
However, today Gadget is the more recognised term, Perhaps Scott was
just trying to be polite and not force the Wookie related motivations -
then again maybe I'm completely wrong and Scott has another reason for
his suggestion.
Ross
[1] http://www.w3.org/TR/widgets/
[2]
http://www.opensocial.org/Technical-Resources/opensocial-spec-v09/Gadgets-API-Specification.html
Re: Bootstrapping RAVE code
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 4/5/11 1:39 PM, "Scott Wilson" <sc...@gmail.com> wrote:
>On 5 Apr 2011, at 18:06, Franklin, Matthew B. wrote:
>
>>
>> On 4/5/11 12:36 PM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Fair enough. We're also +1 for light shindig coupling, as a separate
>>> webapp. So how about the following starter list?
>>>
>>> * User registration and associated actions.
>>>
>>> * Registered user authentication/login and associated actions with
>>> extensibility for OpenID, Grid-style logins, etc.
>>>
>>> * Basic roles, groups.
>>
>> IMHO these first 3 are downstream features that will impact, but don't
>> drive the overall product architecture.
>>
>>>
>>> * Individual gadget rendering and lifecycle management (add, delete,
>>> refresh, views, settings); basic layouts.
>>
>> In terms of infrastructure drivers, I think this is probably one of the
>> places to start. There are a lot of implicit features included in this
>> item some (not by any means all) of which are:
>>
>> * The pages themselves
>> * Types of Pages
>> * Persistance
>> * Layouts
>> * Page Rendering
>> * Core javascript
>> * The widgets & container support
>> * Shindig authorization
>> * Backend data synchronization with Shindig
>> * Security
>> * Inline vs iFrame widgets
>> * Container API implementation
>>
>> So out of this, I suggest the first feature we implement is the basic
>> display of a page and discuss what the infrastructure required to do
>>that
>> is. Specifically, a light-weight object model, rendering engine, page
>> types etc.
>
>Definitely, and I think the list you've got there is a good starting point
>
>Can we agree on some terminology just so we don't get confused? Its easy
>to use terms like Gadget and Widget, but there is also the specific thing
>that Rave manages - and has a model that Rave needs to take care of -
>which needs a name to disambiguate from OpenSocial gadgets, W3C Widgets.
>Maybe just "Rave Gadget"? ("Ravelet"??).
In my mind, widget is the most generic and well understood term for all
types of gadgets/widgets. What about keeping widget as the name rather
than introducing a new term?
>
>
>So something like "A Rave application consists of Rave Pages containing
>Rave Gadgets. Rave Gadgets are typically rendered by a Gadget Container
>such as Apache Shindig"
>
>S
>
>PS I've also been working on some stuff for an EU project involving
>flexible embedded workspaces that include widgets and can adapt to
>different screen types (mobile, tablet, desktop), so I imagine their
>could be quite bit of overlap...
>
>>
>>>
>>>
>>> Marlon
>>>
>>>
>>> On 4/5/11 11:19 AM, Franklin, Matthew B. wrote:
>>>> Thanks Marlon. I was planning on kicking up the discussion today also
>>>> :)
>>>>
>>>> Personally, I don't think that starting with a throwaway is quite the
>>>> right route. I agree that we are stalled on the next steps, and that
>>>>it
>>>> always helps to have code to comment on; but, we already have 2 (soon
>>>>3)
>>>> codebases that we can use as drivers for our discussion.
>>>>
>>>> In my mind, the big question is what does the "10,000m" architecture
>>>> (sorry to use a cliché) look like. Not specifics as to how each
>>>> detailed
>>>> component will work, but what are the general organization principles
>>>>we
>>>> need to follow. For instance, you mentioned creating a skeleton that
>>>> includes Shindig. In our experience, the more loosely coupled the
>>>> application is to Shindig the better. These discussions are more
>>>>about
>>>> ensuring consistency and providing developers some heuristic to follow
>>>> as
>>>> we break out and implement individual features.
>>>>
>>>> I definitely don't mean to imply that we need to architect or design
>>>>the
>>>> whole thing up front. That is an equally bad, if not worse, approach
>>>> than
>>>> throw away in my opinion.
>>>>
>>>> That being said, when it comes to putting together the project
>>>>skeleton,
>>>> Tony, Jesse or I would be more than happy to take a first run.
>>>>
>>>> So back to where do we start? I think the first thing we do is take
>>>>the
>>>> feature list from the wiki and discuss how we want to implement the
>>>> highest priority one, using the existing codebases as reference for
>>>>the
>>>> discussion.
>>>>
>>>> -Matt
>>>>
>>>> On 4/5/11 10:47 AM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>>>>
>>>> Based on previous emails, I think we had consensus on the following
>>>> points: we will start a new code base, and we'll base it on SpringMVC
>>>> framework. Unfortunately that's as far as we've gotten.
>>>>
>>>> I'd like to suggest the following: let's create a skeleton project
>>>>with
>>>> Spring + Shindig and start fleshing it out. This will be a throw-away
>>>> so
>>>> we will want to tag it appropriately. This should hopefully initiate
>>>> more detailed design discussions over email, etc. I think this will
>>>>be
>>>> easier if we have some code to comment on. I realize that there is
>>>>the
>>>> danger that the "throw away" version doesn't actually get thrown away,
>>>> but I think we can accept this risk.
>>>>
>>>> Raminder, Gerald, and I are Spring novices, so we need a volunteer
>>>>from
>>>> Mitre or Surfnet to design the skeleton. I promise we'll add to the
>>>> framework as soon as it is created.
>>>>
>>>>
>>>> What does everyone think? I'm open to other plans and just want to
>>>>see
>>>> things start moving.
>>>>
>>>>
>>>>
>>>> Marlon
>>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iQEcBAEBAgAGBQJNm0UNAAoJEEfVXEODPFIDAMoH/1w2kEz6fCk23JhMEZj5Ha1t
>>> bCI0M15Ed707KkXDDqgQQBq7BQ73F6fVJ2piVqcmzQg1rw/75/6nFdsO+qG47W46
>>> Hp3lHRJ/PnCfaY0whgci/9yq8dJh4vISuv3ybSJN9PHppfsxd+CsHwk29e7nHfFa
>>> +LflXPhZ+ZdXM/84C68HKrEKSazjZcaI1aLM7STibM0Sm5e9ZdU9v1yEkuoYZvYu
>>> 8tDxcNLEDW+pE+170F+Ob1aEl9gergTYgCFu52mOK7uYY7o6CqefcXGHWy4JrFS+
>>> RUjqmMA8FtKm6VyOtl4FThI/VAhT4IEXNpv8AwKJLFM/ogGR5nkAhfY008MhK18=
>>> =WgwF
>>> -----END PGP SIGNATURE-----
>>
Re: Bootstrapping RAVE code
Posted by Scott Wilson <sc...@gmail.com>.
On 5 Apr 2011, at 18:06, Franklin, Matthew B. wrote:
>
> On 4/5/11 12:36 PM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Fair enough. We're also +1 for light shindig coupling, as a separate
>> webapp. So how about the following starter list?
>>
>> * User registration and associated actions.
>>
>> * Registered user authentication/login and associated actions with
>> extensibility for OpenID, Grid-style logins, etc.
>>
>> * Basic roles, groups.
>
> IMHO these first 3 are downstream features that will impact, but don't
> drive the overall product architecture.
>
>>
>> * Individual gadget rendering and lifecycle management (add, delete,
>> refresh, views, settings); basic layouts.
>
> In terms of infrastructure drivers, I think this is probably one of the
> places to start. There are a lot of implicit features included in this
> item some (not by any means all) of which are:
>
> * The pages themselves
> * Types of Pages
> * Persistance
> * Layouts
> * Page Rendering
> * Core javascript
> * The widgets & container support
> * Shindig authorization
> * Backend data synchronization with Shindig
> * Security
> * Inline vs iFrame widgets
> * Container API implementation
>
> So out of this, I suggest the first feature we implement is the basic
> display of a page and discuss what the infrastructure required to do that
> is. Specifically, a light-weight object model, rendering engine, page
> types etc.
Definitely, and I think the list you've got there is a good starting point
Can we agree on some terminology just so we don't get confused? Its easy to use terms like Gadget and Widget, but there is also the specific thing that Rave manages - and has a model that Rave needs to take care of - which needs a name to disambiguate from OpenSocial gadgets, W3C Widgets. Maybe just "Rave Gadget"? ("Ravelet"??).
So something like "A Rave application consists of Rave Pages containing Rave Gadgets. Rave Gadgets are typically rendered by a Gadget Container such as Apache Shindig"
S
PS I've also been working on some stuff for an EU project involving flexible embedded workspaces that include widgets and can adapt to different screen types (mobile, tablet, desktop), so I imagine their could be quite bit of overlap...
>
>>
>>
>> Marlon
>>
>>
>> On 4/5/11 11:19 AM, Franklin, Matthew B. wrote:
>>> Thanks Marlon. I was planning on kicking up the discussion today also
>>> :)
>>>
>>> Personally, I don't think that starting with a throwaway is quite the
>>> right route. I agree that we are stalled on the next steps, and that it
>>> always helps to have code to comment on; but, we already have 2 (soon 3)
>>> codebases that we can use as drivers for our discussion.
>>>
>>> In my mind, the big question is what does the "10,000m" architecture
>>> (sorry to use a cliché) look like. Not specifics as to how each
>>> detailed
>>> component will work, but what are the general organization principles we
>>> need to follow. For instance, you mentioned creating a skeleton that
>>> includes Shindig. In our experience, the more loosely coupled the
>>> application is to Shindig the better. These discussions are more about
>>> ensuring consistency and providing developers some heuristic to follow
>>> as
>>> we break out and implement individual features.
>>>
>>> I definitely don't mean to imply that we need to architect or design the
>>> whole thing up front. That is an equally bad, if not worse, approach
>>> than
>>> throw away in my opinion.
>>>
>>> That being said, when it comes to putting together the project skeleton,
>>> Tony, Jesse or I would be more than happy to take a first run.
>>>
>>> So back to where do we start? I think the first thing we do is take the
>>> feature list from the wiki and discuss how we want to implement the
>>> highest priority one, using the existing codebases as reference for the
>>> discussion.
>>>
>>> -Matt
>>>
>>> On 4/5/11 10:47 AM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>>>
>>> Based on previous emails, I think we had consensus on the following
>>> points: we will start a new code base, and we'll base it on SpringMVC
>>> framework. Unfortunately that's as far as we've gotten.
>>>
>>> I'd like to suggest the following: let's create a skeleton project with
>>> Spring + Shindig and start fleshing it out. This will be a throw-away
>>> so
>>> we will want to tag it appropriately. This should hopefully initiate
>>> more detailed design discussions over email, etc. I think this will be
>>> easier if we have some code to comment on. I realize that there is the
>>> danger that the "throw away" version doesn't actually get thrown away,
>>> but I think we can accept this risk.
>>>
>>> Raminder, Gerald, and I are Spring novices, so we need a volunteer from
>>> Mitre or Surfnet to design the skeleton. I promise we'll add to the
>>> framework as soon as it is created.
>>>
>>>
>>> What does everyone think? I'm open to other plans and just want to see
>>> things start moving.
>>>
>>>
>>>
>>> Marlon
>>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iQEcBAEBAgAGBQJNm0UNAAoJEEfVXEODPFIDAMoH/1w2kEz6fCk23JhMEZj5Ha1t
>> bCI0M15Ed707KkXDDqgQQBq7BQ73F6fVJ2piVqcmzQg1rw/75/6nFdsO+qG47W46
>> Hp3lHRJ/PnCfaY0whgci/9yq8dJh4vISuv3ybSJN9PHppfsxd+CsHwk29e7nHfFa
>> +LflXPhZ+ZdXM/84C68HKrEKSazjZcaI1aLM7STibM0Sm5e9ZdU9v1yEkuoYZvYu
>> 8tDxcNLEDW+pE+170F+Ob1aEl9gergTYgCFu52mOK7uYY7o6CqefcXGHWy4JrFS+
>> RUjqmMA8FtKm6VyOtl4FThI/VAhT4IEXNpv8AwKJLFM/ogGR5nkAhfY008MhK18=
>> =WgwF
>> -----END PGP SIGNATURE-----
>
Re: Bootstrapping RAVE code
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sounds good to me. What is the next step? Can you send pointers to the OSEC code that illustrate your current approach?
Marlon
>> In terms of infrastructure drivers, I think this is probably one of the
>> places to start. There are a lot of implicit features included in this
>> item some (not by any means all) of which are:
>
>> * The pages themselves
>> * Types of Pages
>> * Persistance
>> * Layouts
>> * Page Rendering
>> * Core javascript
>> * The widgets & container support
>> * Shindig authorization
>> * Backend data synchronization with Shindig
>> * Security
>> * Inline vs iFrame widgets
>> * Container API implementation
>
>> So out of this, I suggest the first feature we implement is the basic
>> display of a page and discuss what the infrastructure required to do that
>> is. Specifically, a light-weight object model, rendering engine, page
>> types etc.
>
>
>
> Marlon
>
>
> On 4/5/11 11:19 AM, Franklin, Matthew B. wrote:
>>>> Thanks Marlon. I was planning on kicking up the discussion today also
>>>> :)
>>>>
>>>> Personally, I don't think that starting with a throwaway is quite the
>>>> right route. I agree that we are stalled on the next steps, and that it
>>>> always helps to have code to comment on; but, we already have 2 (soon 3)
>>>> codebases that we can use as drivers for our discussion.
>>>>
>>>> In my mind, the big question is what does the "10,000m" architecture
>>>> (sorry to use a cliché) look like. Not specifics as to how each
>>>> detailed
>>>> component will work, but what are the general organization principles we
>>>> need to follow. For instance, you mentioned creating a skeleton that
>>>> includes Shindig. In our experience, the more loosely coupled the
>>>> application is to Shindig the better. These discussions are more about
>>>> ensuring consistency and providing developers some heuristic to follow
>>>> as
>>>> we break out and implement individual features.
>>>>
>>>> I definitely don't mean to imply that we need to architect or design the
>>>> whole thing up front. That is an equally bad, if not worse, approach
>>>> than
>>>> throw away in my opinion.
>>>>
>>>> That being said, when it comes to putting together the project skeleton,
>>>> Tony, Jesse or I would be more than happy to take a first run.
>>>>
>>>> So back to where do we start? I think the first thing we do is take the
>>>> feature list from the wiki and discuss how we want to implement the
>>>> highest priority one, using the existing codebases as reference for the
>>>> discussion.
>>>>
>>>> -Matt
>>>>
>>>> On 4/5/11 10:47 AM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>>>>
>>>> Based on previous emails, I think we had consensus on the following
>>>> points: we will start a new code base, and we'll base it on SpringMVC
>>>> framework. Unfortunately that's as far as we've gotten.
>>>>
>>>> I'd like to suggest the following: let's create a skeleton project with
>>>> Spring + Shindig and start fleshing it out. This will be a throw-away
>>>> so
>>>> we will want to tag it appropriately. This should hopefully initiate
>>>> more detailed design discussions over email, etc. I think this will be
>>>> easier if we have some code to comment on. I realize that there is the
>>>> danger that the "throw away" version doesn't actually get thrown away,
>>>> but I think we can accept this risk.
>>>>
>>>> Raminder, Gerald, and I are Spring novices, so we need a volunteer from
>>>> Mitre or Surfnet to design the skeleton. I promise we'll add to the
>>>> framework as soon as it is created.
>>>>
>>>>
>>>> What does everyone think? I'm open to other plans and just want to see
>>>> things start moving.
>>>>
>>>>
>>>>
>>>> Marlon
>>>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNnJpWAAoJEEfVXEODPFIDvrEH+gOHMoxm7aBszTRwKOD16YtO
ssAMPGvb8OVFk33/mqJmUq1+6i3pi8koFrL93hbnEiwdx9ZnO3o/6+1lY0Ak0uFZ
+Pz5b7RGz2NMCgwxDGQ0jPHXXq1ehAJAyphWrIh7bkwOwuIR7fVygnQyw1JYrGb1
hiZ+H6xray3XHysWV61VXCjKNLMY0bpA/YzA0JM7gWSPv30xUPAVw66XkmTQGcf0
4kuPsV2ieLwhe7JR7Bhddox8Pvw1eQqgXP3i5AlUi/YMUchb3NCi+2am8sMFPjR7
zs3cMLfYLjYcnPPIjmMz/ljywNnGPbfA4gkDHPzECUPGWGJcFZ8EXLdQw8zywac=
=SN1E
-----END PGP SIGNATURE-----
Re: Bootstrapping RAVE code
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 4/5/11 12:36 PM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Fair enough. We're also +1 for light shindig coupling, as a separate
>webapp. So how about the following starter list?
>
>* User registration and associated actions.
>
>* Registered user authentication/login and associated actions with
>extensibility for OpenID, Grid-style logins, etc.
>
>* Basic roles, groups.
IMHO these first 3 are downstream features that will impact, but don't
drive the overall product architecture.
>
>* Individual gadget rendering and lifecycle management (add, delete,
>refresh, views, settings); basic layouts.
In terms of infrastructure drivers, I think this is probably one of the
places to start. There are a lot of implicit features included in this
item some (not by any means all) of which are:
* The pages themselves
* Types of Pages
* Persistance
* Layouts
* Page Rendering
* Core javascript
* The widgets & container support
* Shindig authorization
* Backend data synchronization with Shindig
* Security
* Inline vs iFrame widgets
* Container API implementation
So out of this, I suggest the first feature we implement is the basic
display of a page and discuss what the infrastructure required to do that
is. Specifically, a light-weight object model, rendering engine, page
types etc.
>
>
>Marlon
>
>
>On 4/5/11 11:19 AM, Franklin, Matthew B. wrote:
>> Thanks Marlon. I was planning on kicking up the discussion today also
>>:)
>>
>> Personally, I don't think that starting with a throwaway is quite the
>> right route. I agree that we are stalled on the next steps, and that it
>> always helps to have code to comment on; but, we already have 2 (soon 3)
>> codebases that we can use as drivers for our discussion.
>>
>> In my mind, the big question is what does the "10,000m" architecture
>> (sorry to use a cliché) look like. Not specifics as to how each
>>detailed
>> component will work, but what are the general organization principles we
>> need to follow. For instance, you mentioned creating a skeleton that
>> includes Shindig. In our experience, the more loosely coupled the
>> application is to Shindig the better. These discussions are more about
>> ensuring consistency and providing developers some heuristic to follow
>>as
>> we break out and implement individual features.
>>
>> I definitely don't mean to imply that we need to architect or design the
>> whole thing up front. That is an equally bad, if not worse, approach
>>than
>> throw away in my opinion.
>>
>> That being said, when it comes to putting together the project skeleton,
>> Tony, Jesse or I would be more than happy to take a first run.
>>
>> So back to where do we start? I think the first thing we do is take the
>> feature list from the wiki and discuss how we want to implement the
>> highest priority one, using the existing codebases as reference for the
>> discussion.
>>
>> -Matt
>>
>> On 4/5/11 10:47 AM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>>
>> Based on previous emails, I think we had consensus on the following
>> points: we will start a new code base, and we'll base it on SpringMVC
>> framework. Unfortunately that's as far as we've gotten.
>>
>> I'd like to suggest the following: let's create a skeleton project with
>> Spring + Shindig and start fleshing it out. This will be a throw-away
>>so
>> we will want to tag it appropriately. This should hopefully initiate
>> more detailed design discussions over email, etc. I think this will be
>> easier if we have some code to comment on. I realize that there is the
>> danger that the "throw away" version doesn't actually get thrown away,
>> but I think we can accept this risk.
>>
>> Raminder, Gerald, and I are Spring novices, so we need a volunteer from
>> Mitre or Surfnet to design the skeleton. I promise we'll add to the
>> framework as soon as it is created.
>>
>>
>> What does everyone think? I'm open to other plans and just want to see
>> things start moving.
>>
>>
>>
>> Marlon
>>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iQEcBAEBAgAGBQJNm0UNAAoJEEfVXEODPFIDAMoH/1w2kEz6fCk23JhMEZj5Ha1t
>bCI0M15Ed707KkXDDqgQQBq7BQ73F6fVJ2piVqcmzQg1rw/75/6nFdsO+qG47W46
>Hp3lHRJ/PnCfaY0whgci/9yq8dJh4vISuv3ybSJN9PHppfsxd+CsHwk29e7nHfFa
>+LflXPhZ+ZdXM/84C68HKrEKSazjZcaI1aLM7STibM0Sm5e9ZdU9v1yEkuoYZvYu
>8tDxcNLEDW+pE+170F+Ob1aEl9gergTYgCFu52mOK7uYY7o6CqefcXGHWy4JrFS+
>RUjqmMA8FtKm6VyOtl4FThI/VAhT4IEXNpv8AwKJLFM/ogGR5nkAhfY008MhK18=
>=WgwF
>-----END PGP SIGNATURE-----
Re: Bootstrapping RAVE code
Posted by Marlon Pierce <mp...@cs.indiana.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fair enough. We're also +1 for light shindig coupling, as a separate webapp. So how about the following starter list?
* User registration and associated actions.
* Registered user authentication/login and associated actions with extensibility for OpenID, Grid-style logins, etc.
* Basic roles, groups.
* Individual gadget rendering and lifecycle management (add, delete, refresh, views, settings); basic layouts.
Marlon
On 4/5/11 11:19 AM, Franklin, Matthew B. wrote:
> Thanks Marlon. I was planning on kicking up the discussion today also :)
>
> Personally, I don't think that starting with a throwaway is quite the
> right route. I agree that we are stalled on the next steps, and that it
> always helps to have code to comment on; but, we already have 2 (soon 3)
> codebases that we can use as drivers for our discussion.
>
> In my mind, the big question is what does the "10,000m" architecture
> (sorry to use a cliché) look like. Not specifics as to how each detailed
> component will work, but what are the general organization principles we
> need to follow. For instance, you mentioned creating a skeleton that
> includes Shindig. In our experience, the more loosely coupled the
> application is to Shindig the better. These discussions are more about
> ensuring consistency and providing developers some heuristic to follow as
> we break out and implement individual features.
>
> I definitely don't mean to imply that we need to architect or design the
> whole thing up front. That is an equally bad, if not worse, approach than
> throw away in my opinion.
>
> That being said, when it comes to putting together the project skeleton,
> Tony, Jesse or I would be more than happy to take a first run.
>
> So back to where do we start? I think the first thing we do is take the
> feature list from the wiki and discuss how we want to implement the
> highest priority one, using the existing codebases as reference for the
> discussion.
>
> -Matt
>
> On 4/5/11 10:47 AM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>
> Based on previous emails, I think we had consensus on the following
> points: we will start a new code base, and we'll base it on SpringMVC
> framework. Unfortunately that's as far as we've gotten.
>
> I'd like to suggest the following: let's create a skeleton project with
> Spring + Shindig and start fleshing it out. This will be a throw-away so
> we will want to tag it appropriately. This should hopefully initiate
> more detailed design discussions over email, etc. I think this will be
> easier if we have some code to comment on. I realize that there is the
> danger that the "throw away" version doesn't actually get thrown away,
> but I think we can accept this risk.
>
> Raminder, Gerald, and I are Spring novices, so we need a volunteer from
> Mitre or Surfnet to design the skeleton. I promise we'll add to the
> framework as soon as it is created.
>
>
> What does everyone think? I'm open to other plans and just want to see
> things start moving.
>
>
>
> Marlon
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJNm0UNAAoJEEfVXEODPFIDAMoH/1w2kEz6fCk23JhMEZj5Ha1t
bCI0M15Ed707KkXDDqgQQBq7BQ73F6fVJ2piVqcmzQg1rw/75/6nFdsO+qG47W46
Hp3lHRJ/PnCfaY0whgci/9yq8dJh4vISuv3ybSJN9PHppfsxd+CsHwk29e7nHfFa
+LflXPhZ+ZdXM/84C68HKrEKSazjZcaI1aLM7STibM0Sm5e9ZdU9v1yEkuoYZvYu
8tDxcNLEDW+pE+170F+Ob1aEl9gergTYgCFu52mOK7uYY7o6CqefcXGHWy4JrFS+
RUjqmMA8FtKm6VyOtl4FThI/VAhT4IEXNpv8AwKJLFM/ogGR5nkAhfY008MhK18=
=WgwF
-----END PGP SIGNATURE-----
Re: Bootstrapping RAVE code
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
Thanks Marlon. I was planning on kicking up the discussion today also :)
Personally, I don't think that starting with a throwaway is quite the
right route. I agree that we are stalled on the next steps, and that it
always helps to have code to comment on; but, we already have 2 (soon 3)
codebases that we can use as drivers for our discussion.
In my mind, the big question is what does the "10,000m" architecture
(sorry to use a cliché) look like. Not specifics as to how each detailed
component will work, but what are the general organization principles we
need to follow. For instance, you mentioned creating a skeleton that
includes Shindig. In our experience, the more loosely coupled the
application is to Shindig the better. These discussions are more about
ensuring consistency and providing developers some heuristic to follow as
we break out and implement individual features.
I definitely don't mean to imply that we need to architect or design the
whole thing up front. That is an equally bad, if not worse, approach than
throw away in my opinion.
That being said, when it comes to putting together the project skeleton,
Tony, Jesse or I would be more than happy to take a first run.
So back to where do we start? I think the first thing we do is take the
feature list from the wiki and discuss how we want to implement the
highest priority one, using the existing codebases as reference for the
discussion.
-Matt
On 4/5/11 10:47 AM, "Marlon Pierce" <mp...@cs.indiana.edu> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Based on previous emails, I think we had consensus on the following
>points: we will start a new code base, and we'll base it on SpringMVC
>framework. Unfortunately that's as far as we've gotten.
>
>I'd like to suggest the following: let's create a skeleton project with
>Spring + Shindig and start fleshing it out. This will be a throw-away so
>we will want to tag it appropriately. This should hopefully initiate
>more detailed design discussions over email, etc. I think this will be
>easier if we have some code to comment on. I realize that there is the
>danger that the "throw away" version doesn't actually get thrown away,
>but I think we can accept this risk.
>
>Raminder, Gerald, and I are Spring novices, so we need a volunteer from
>Mitre or Surfnet to design the skeleton. I promise we'll add to the
>framework as soon as it is created.
>
>
>What does everyone think? I'm open to other plans and just want to see
>things start moving.
>
>
>
>Marlon
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iQEcBAEBAgAGBQJNmyttAAoJEEfVXEODPFID1nsH/ArayUOLnfu9UEH5CoR5iVwH
>njWgUnO2vd0GoCAw/94hSiFPQaCXBuoCs7eT1xS4ezpn4hljGwZFI2K5/73fb0S2
>MDxVUqgTBgcZLlI6fnN9EAsinLCugr6LrO3PRM9IakKutoYJFczOsasQ8JDyYPrh
>63GYiLgDKuFGcbHoh20sTfPnVRoXklLbdH131Z+TIEBFvVuQlGigdEPXhrauAvvg
>OmyPuDhSg+fLtj9mQkhBENPG5fHgvE6/LdCPg1EJi/OUTw7/OJzY2euMmDHsYBTG
>nmdAKlnnWQxwPXoGvkzGWMoFcLXOWr+7TqSPaGTZ+4F1N9FRpUxGAVozrw550Jc=
>=1dJa
>-----END PGP SIGNATURE-----