[Cosmo-dev] Re: Discussion of hibernate data model

[Charles Mattair]

Instead of patches, why not create a subversion repository branch with
limited write access and let us submit changes to that.  I suspect the
pending scooby-cosmo merge is going to touch a lot of the same codes
we do and patches are going prove problematical.  Also, the initial
cuts at this aren't going to work real well and development should
proceed faster if we all have access to the full suite.

Given that, our initial effort is going to be refactoring the object
model.

cgm

> 31 jul 12:26
> 
> On 7/28/06, rletness at simdeskcorp.com <rletness at simdeskcorp.com> wrote:
> 
>  > Brian,
>  >
>  > Charles and I have been thinking about what the best way to go about
>  > re-factoring this data model stuff is.  We have a few questions.  By the
>  > way, we figured some of these questions are pretty specific to the code
>  > so we didn't copy to the list.
> 
> 
> i think the osaf community folks would prefer everything to go to the
> list. their aim is complete transparency.
> 
>  > Going through the code, we were trying to figure out what the object
>  > model defined in org.osaf.cosmo.model is used for.  It looks like these
>  > objects are mainly used by the cosmo ui.  Is that correct?  As far as I
>  > could tell, the caldav classes (that extend from the jcr-server classes)
>  > operate on JCR nodes directly, instead of a "Calendar" or "Event"
>  > objects.   What do you think about using this object model for the new
>  > service apis?
> 
> 
> you're right - the jcr-server classes use jcr directly, whereas the
> rest of the server goes through the cosmo service apis. that's the
> purpose of my jcr-server project - to re-implement those interfaces
> using the cosmo service apis. so yeah, we should be using/updating the
> existing model classes as necessary.
> 
>  > In the data model we are proposing, the JCR node would be replaced with
>  > the notion of a resource, or as you suggested "item".  We like the term
>  > "resource" because that is what the current code uses and that is what
>  > the underlying dav model implies.  Instead of exposing the core
>  > "resource" or "item" objects, we would expose subclasses such as
>  > "Calendar" and "Event" that would derive from the underlying class.
> 
> 
> i'd really like to use "item". one of my goals for this project (and
> for upcoming chandler/cosmo sharing work) is to remove the dav-isms
> from the data and object model. item is also symmetrical with the
> equivalent concept in the chandler data model. for that matter, the
> chandler term for what i've been calling type is "kind" (event,
> contact, task, image, movie would all be kinds).
> 
>  > We have prototyped a first approximation of a database schema  (and
>  > hibernate mapping files/classes) that pretty closely mirrors the JCR
>  > model.  We have done some initial sanity tests to validate performance
>  > (shoving 250K events and 1.75M properties into a MySQL db and performing
>  > basic queries) and we are in the ballpark.  We are ready to define an
>  > object model and service apis that will be surfaced in the cosmo world.
> 
> 
> awesome :)
> 
>  > So then comes the question of what services we need to expose.  It looks
>  > like we need to provide new implementations of UserService and
>  > HomeDirectoryService (or maybe just the daos), and then provide a number
>  > of services for calendar and dav object access.  These would be the
>  > services that you would use when re-writing the jcr-server component.
>  > Speaking of which, how do you want to coordinate this?  We can start
>  > pretty soon on these services, so what would be the best way to
>  > collobarate?  We could give you the api interfaces and then you could
>  > start coding the jcr-server based on these(letting us know what changes
>  > to the api you need). Suggestions?
> 
> 
> i think the first step should be providing alternate implementations
> of the dao interfaces. that should provide the least amount of
> turbulence in the rest of the system. then, as we re-implement
> jcr-server and merge scooby into cosmo and replace its use of caldav,
> we'll need to extend the service apis for operations like "get all
> calendars in my home collection".
> 
>  > Also, if you think of any Chandler requirements outside of a dav/caldav
>  > model, let us know so we can make sure there will be some way to support
>  > them.
> 
> 
> will do. the various sharing format threads are still in brainstorming
> mode, but i expect in the next several weeks we'll begin converging on
> a concrete plan.
> 
> 31 jul 12:29
> 
> On 7/31/06, Brian Moseley <bcm at osafoundation.org> wrote:
> 
>  > i think the first step should be providing alternate implementations
>  > of the dao interfaces. that should provide the least amount of
>  > turbulence in the rest of the system. then, as we re-implement
>  > jcr-server and merge scooby into cosmo and replace its use of caldav,
>  > we'll need to extend the service apis for operations like "get all
>  > calendars in my home collection".
> 
> 
> oh and, mechanically, i'll open a bug in bugzilla for the hibernate
> project that you can attach patches to. i'll make an svn branch in
> osaf's repository where i'll apply those patches and do the jcr-server
> work.
> 
>