On 4/7/11 10:26 AM, "Ate Douma" <[email protected]> wrote: >On 04/07/2011 04:14 PM, Raminderjeet Singh wrote: >> I suggested DFD's for everyone to understand the current models and >>find a gap if any or someone need it in different way. Models can be >>changed quickly to fulfill requirements . I also believe in looking into >>the code. As soon as we decide on build system and Mitre move the >>Models, I can help with writing the unit tests for models. >> >> Another question i have is to use OpenJPA or Hibernate JPA adaptors to >>connect to backend. I am using Hibernate adaptor and its working well >>but i remember we discussing license problems with that in Apache. >A direct dependency on Hibernate would be a problem because of its LGPL >license. >If we use JPA shouldn't it be theoretically possible to use OpenJPA by >default >but allow switching to Hibernate (JPA) by the end-users? >Of course any JPA provider has extensions and allow customizations which >tend to >seep into the code base, potentially making this more difficult than it >sounds.
It *should* be possible to code only to the spec, and not use provider specific features. In OSEC, we only have a couple of instances where we used a Eclipselink annotation, and those might be possible to get rid of with a different object model. >But at least we could strive, and if desired even explicitly provide >tests, to >support Hibernate JPA as well. > >> >> Thanks >> Raminder >> >> On Apr 7, 2011, at 8:03 AM, Franklin, Matthew B. wrote: >> >>> >>> >>> 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/s >>>>>rc/ >>>>> 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----- >>>> >>>> >>> >> > >
