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