On 4/7/11 4:34 AM, "Ate Douma" <[email protected]> wrote:
>On 04/07/2011 12:52 AM, Franklin, Matthew B. wrote: >> When looking at OSEC, I would start with the object model >>(http://svn.apache.org/repos/asf/incubator/rave/donations/mitre-osec/src/ >>org/mitre/portal/model/). The Page is the top level object and >>represents the layout of gadgets that the user sees. >> >Sounds good to me. Starting with the core (basic) Object model just make >sense. > >A remark upfront concerning Page being the top level (layout) object: I'm >fine >we start out with a simple layout model first. >However in my experience with portal layout in general we'll probably >need a >more fine-grained nested/fragment based layout model later on to support >"groups" or "sets" of layout elements which can be pulled in or included >within >a higher fragment level. The new OpenSocial 2.0 proposal for Spaces also >already >hints at this. In OSEC a Page has a list of regions that contain the gadgets, with each region containing a set of gadget mappings. It is a little more fragmented than just a Page with gadgets. > >At Apache Jetspeed we've been using hierarchical fragment based layout >(PSML, >Portal Structured Markup Language) for years, with the root fragment >representing a Page. We even had to add nested fragment references, >includes and >fragment inheritance models to support all the layout requirements we >faced for >customers. >I'm certainly not suggesting we should use the PSML model for Rave but it >might >be good not to "tie" layout elements and configuration too strongly to >only a >single Page concept. To be clear, I am very open to a different object model or way of representing the layouts of Widgets in pages. I am highly in favor of simple, flexible models. > >Ate > >> -Matt >> >> >> >> -----Original Message----- >> From: Marlon Pierce [mailto:[email protected]] >> Sent: Wednesday, April 06, 2011 12:53 PM Eastern Standard Time >> To: [email protected] >> Subject: Re: Bootstrapping RAVE code >> >> -----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"<[email protected]> 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----- > >
