> -----Original Message-----
> From: David Sean Taylor [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 02, 2001 10:52 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Putting .psml/markup info into database
>
>
> > Hi,
> >
> > I'm trying to do certain modifications to Jetspeed. The main
> > requirement we
> > have is, we want to put .psml/markup information into
> > database. We don't
> > want all those .psml files lying around in file system. And
> > as number of
> > users grow, it will just flood the file system.
> >
> > Here are some of my findings and conclusions:
> > 0. Need to define a database schema, which will allow to
> > store per group/per
> > role/per user specific .psml information in to database.
>
> There is already a 'schema' for PSML: src/xml/schema/psml.xsd
>
Huh. That's a good point. Actually, I had looked at the psml.xsd and was
about to explore the schema, before creating a new one. Thanks for the
pointer though.
> This XML Schema is the definitive schema for PSML.
> From the xml schema, we use Castor to create the Java object
> model for PSML.
> I believe the database schema to be an implementation detail for a
> relational database implementation.
>
> > 1. The current Profiler Manager Service
> > (org.apache.jetspeed.services.profile.JetspeedProfileManagerSe
> > rvice) needs
> > to be rewritten.
>
>
> I think you want to look at the
> org.apache.jetspeed.services.psmlmanager.PsmlManagerService
> interface - this
> has more to do with the storage and retrieval of PSML.
Well, I guess, you are looking at the current CVS HEAD. I am planning to use
the current 1.3a1 release, which doesn't have PsmlManagerService (and as
1.3a2 release date is not yet available).
>
> For the next release, I'd like to refactor the Profiler
> service to better
> use the PsmlManagerService to persist and query psml.
>
> That said, I disagree that the JetspeedProfileManagerService should be
> rewritten.
> It is a good implementation of a file-system based profiling system.
Its a great implementation. I am not saying we should get rid of it, may be
I put it wrong.
> Wouldn't you prefer to have two implementations: a file-based and
> database-based implementation?
Yeah, ofcourse. I would prefer that.
>
> Both would implement the same interface:
> org.apache.jetspeed.services.profiler.ProfilerService.
> Thus you can plug in the new Service impl. without disrupting
> any other code
> in the system.
That's perfect. "Code to an interface..never to an implementation!"
> And for those who chose not to use database storage for their
> psml, they are
> still free to store it in the file system with the
> JetspeedProfileManagerService.
>
Yep.
> This was the design intention from the beginning.
>
> > 2. The new rewritten class can be plugged into Jetspeed thro'
> > properties
> > file.
> > 3. Also, org.apache.jetspeed.cache.disk package needs to be
> > modified. It
> > curently handles remote and local urls. It needs handle the
> > database storage
> > to get the required information if the newly written Profiler
> > Manager has to
> > use Disk Cache (which it will now, as we don't want to go
> to database
> > everytime user logs in).
>
> You shouldn't have to touch the Disk Cache.
> The impl. of the new DatabaseProfileManagerService would most
> likely use
> JDBC, or perhaps Castor JDO...
> Take a look at the CastorPsmlManagerService. It already makes use of a
> WeakReference memory cache.
Huh. That's a good hint.
>
> >
> > Will someone from the Jetspeed development team comment on
> > this, please? Or
> > is there a plan to incorporate this as a new feature?
> >
>
> Sure. If you write it, we would be glad to incorporate it :)
> However, we are not planning on writing this for the 1.3a2 release.
When is 1.3a2 scheduled for? B'cse if we do all those changes in current
release (1.3a1) it would have to be redone in 1.3a2. And as release date for
1.3a2 is not yet out, we are in a kind of flux.
Thanks,
-Atul
> I think it would be a good candidate for 1.3a3, along with
> the refactoring
> of the Profiler and PSMLManager, which is already planned.
>
> > Thanks,
> >
> > -Atul
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
