On 8 Apr 2011, at 12:43, Ciancetta, Jesse E. wrote: > > >> -----Original Message----- >> From: Woonsan Ko [mailto:[email protected]] >> Sent: Thursday, April 07, 2011 5:02 PM >> To: [email protected] >> Subject: Re: Bootstrapping RAVE code >> >> >> --- On Thu, 4/7/11, Scott Wilson <[email protected]> wrote: >> >>> From: Scott Wilson <[email protected]> >>> Subject: Re: Bootstrapping RAVE code >>> To: [email protected] >>> Date: Thursday, April 7, 2011, 6:46 PM >>> On 7 Apr 2011, at 16:56, Ciancetta, >>> Jesse E. wrote: >>> >>>>> -----Original Message----- >>>>> From: Franklin, Matthew B. [mailto:[email protected]] >>>>> Sent: Thursday, April 07, 2011 10:23 AM >>>>> To: [email protected] >>>>> Subject: Re: Bootstrapping RAVE code >>>>> >>>>> I haven't used OpenJPA, but would be willing to >>> for a reference >>>>> persistence implementation. >>>> >>>> +1 for OpenJPA. Internally there's a good chance >>> we'll swap it out for EclipseLink JPA since that's what >>> we're running on now, but as Ate pointed out already -- as >>> long as we stick to "vanilla" JPA that should (in theory, >>> and hopefully in practice) be relatively easy to do. >>> >>> >>>>> When we were laying out the feature list, we all >>> agreed that we need to >>>>> build an object model that supports flexible >>> persistence mechanisms and >>>>> allow Rave users to inject their own >>> implementations over ours, if they >>>>> so >>>>> choose. To that end, I would rather try to >>> identify a less circular >>>>> model >>>>> than OSEC. >>>> >>>> +1 for the shallower object model too. Matt and >>> I have talked about this a bit internally so I know what >>> he's getting at already -- and maybe it's clear already to >>> everyone else already too -- but just in case it isn't >>> (since I'm not sure it would be to me without my additional >>> context) I'll add a little more background to this. >>>> >>>> I think this basically comes down to the fact that JPA >>> supports lazily loaded relationships -- so you can have >>> objects which have lots of relationships hanging off of them >>> and only pay the cost of fetching those related entities >>> when you actually need them. I think that's pretty >>> much standard operating procedure when using JPA (and is >>> really nice to have) but it seems like it makes it almost >>> impossible to replace the backend persistence strategy with >>> something that doesn't support this type of lazy >>> loading. >>>> >>>> For example if someone were to try to replace the JPA >>> based repositories in OSEC with JDBC based repositories -- >>> to assemble and return a Page object you'd also have to >>> fetch all the Regions on that page, and for each Region >>> you'd have to fetch the RegionGadget's in that Region, and >>> for each RegionGadget you'd have to... etc... >>> And you'd have to do all that work up front even if the >>> caller didn't really need all of those objects (or you'd >>> have to manually add support to the domain objects to do it >>> lazily). Not that I think anyone wants to use JDBC in >>> place of JPA but I think the same problem likely applies >>> with some types of NoSQL stores which I think people may >>> want to use. >>>> >>>> So I'd be curious to see how a flatter object model >>> (still JPA based for the reference implementation) might >>> work out. >>> >>> Well I'm all for a simple implementation out-of-the-box >>> with Rave. Having experienced JPA and JCR and Hibernate I'd >>> quite like the opportunity to just use a flat noSQL backend >>> as even though frameworks like JPA are "easier" for Java >>> developers than the even worse ORM alternatives, they are >>> still Configuration Hell compared with platforms on other >>> languages. >>> >>> Personally I'd like to be able to use Redis as the backed >>> store. >> >> That sounds good, but I hope to have SPIs to allow multiple backend >> stores support (DB, JCR, noSQL, ...). For example, RaveWidgetRegistry, >> RavePageManager, etc. can be considered. >> This will allow someone to provide patches for a different backend >> stores. I would love to have noSQL backend support, too. >> >> If the question is about an initial SPI implementation, I would choose >> OpenJPA because the donated codes seem to be using DB stores and JPA- >> like technologies. That seems okay for the initial phase. > > Another reason I think providing JPA based repositories out of the box might > make sense is that my sense is RDBMS's are likely still the lowest common > denominator when it comes to > already-installed-and-available-for-immediate-use persistent stores. > > I know there's tons of buzz around all of the different NoSQL stores these > days, but I'm guessing almost all IT shops have a well supported RDBMS > already installed but I don't think that would necessarily be true for any > NoSQL store we might choose (by well supported I mean well supported by their > own IT folks -- so it's already there for them to use -- they don't have to > try to sell their IT folks on any new technology). > > Although I have to admit I don't deal with other external IT shops very often > -- so maybe some of the other folks on this list who deal with more > commercial customers can comment further on what may or may not be commonly > available in most IT shops these days. Although even that might not be a > good indicator -- I think the people on this list who deal with commercial > customers are very innovative forward thinking shops who likely attract > innovative forward thinking customers... Maybe there's some recent survey > data or something available that we can draw on...
OK, maybe there are two different types of interest here: 1. For production, it makes sense to connect to the commonly-supported database offered by your organisation, in which case some sort of ORM is usually needed, and JPA is a very good fit here. 2. For development and trying it out, it makes sense to be able to just stop and start the app quickly without having to have any other services to set up, and to be able to work with the models without having to edit half a dozen XML files each time you try to add or remove a property. In Wookie I don't think we've got it quite right - we have JPA and JCR interfaces, which means a lot of production flexibility, but its a lot of (very boring) code to maintain, and changing any part of the data model is a real pain. (I keep meaning to do a minor refactor - move a couple of properties into its own bean class - but the overhead of the JPA stuff has put me off two attempts at it already...) Not sure how - or even if - this can be resolved... > >> Regards, >> >> Woonsan >> >>> >>> >>>> >>>>> I also think we can probably identify other >>> simplification areas. Much >>>>> of >>>>> the model of OSEC ties back to a container object, >>> which was in support >>>>> of >>>>> running multiple distinct containers within the >>> same application. A >>>>> container in this sense is a distinct entry point >>> (think more along the >>>>> lines of multi-tenant), providing logical >>> separation of all data. I am >>>>> not sure whether this is a pattern we would like >>> to continue in Rave, >>>>> but >>>>> am open to all discussions. >>>> >>>> To add to this -- Shindig also has the concept of >>> supporting multiple containers on its end too -- although I >>> don't know how well that actually works in practice. >>> I've noted issues with the Shindig configuration process >>> taking one value that should be per container and using it >>> across the board for all containers it's supporting (which >>> in and of itself is just a bug, but it makes me wonder if >>> this is something that was just there from the beginning or >>> something they really use). >>>> >>>> We don't actually use this internally and it's caused >>> confusion with some others who have looked at our code in >>> the past so I'd be +1 for eliminating it. >>> >>> It is confusing - lets keep to the Rave ethos of keeping it >>> simple and leave it out... >>> >>>> >>>>> -Matt >>>>> >>>>> On 4/7/11 10:14 AM, "Raminderjeet Singh" <[email protected]> >>>>> 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. >>>>>> >>>>>> 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/sr >>>>>>>>> c/ >>>>>>>>> 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----- >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>>
