> David Sean Taylor wrote: > Subject: Re: [J2] What's wrong with jcr [was: Menu Implementation] > > On Jun 24, 2004, at 12:49 PM, Tim Reilly wrote: > [snipped for space: see archive at http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] che.org&msgNo=15577 ] > > Thoughts? > > > I think its a great idea
Me too. Even thought this alpha demo has some issues (I'm not a complaining, I'm glad the folks at Day released early b/c despite any bugs;) I could see in a real sense (much better than after reading the jsr) creating the node types in the j2 namespace and how it would define the properties and other allowed node types in the heirarchy. It was exciting to see how this might work with the j2 types discussed here and then think about the interoperability possibilities. I could also see for example where the profiler might use an xpath expression to locate the correct child node to display based on various rules. The import/export is nice too. > On the other hand its a lot of work to implement this complex > specification Yes, true, important condsideration. I think a lot of the community is looking forward to a J2 release - so it may be a risk in both the fact that the spec is non-final, as well that creating the underlying implementation would take some time. There is some ongoing work in slide's cvs under proposals/jcrri not sure where it's at. Perhaps my question is how would one introduce the api after a release of J2 (if J2 wanted to support this)? Perhaps dual support for both a native api and the jcr api? Is it possible to bridge or wrap the existing code with limited jcr functionality to avoid a dual api or a later change? If you were to creating an underlying implementation to ship with jetspeed, would you use xml, database, filesystem, some mix? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
