[EMAIL PROTECTED] wrote:
>
> > +1. The only problem, and this is just a general technical problem not
> > really Jetspeed related. Current DB absctraction/implementation APIs
> > don't lend themselves to using XML that well. I would love to see a way
> > to hide the DB persistence through an Avalon Block interface. We can
> > them provide this back to the API
> >
> > Portlet API
> > |
> > Factory
> > |
> > Data Snap-in Framework ( Avalon )
> > |
> > | |
> > XML Database (OPL, Castor JDO, Expresso DB impl, etc)
>
> I was thinking of just storing the customized defaultPortlets as a VARCHAR.
>
> I know this in some ways defeats the abstract advantages of using an
> "XML-capable DBMS," but I think we can do this reasonably because the field is
> generally accessed in its entirety. That is, we're usually going to read
> this record when a user signs in (or write when saving settings) and then we
> want the whole thing, which can then be parsed or have whatever Castor does
> done to it.
But that IMO is worse than storing it as <user>.xml on the file system.
- it is slower
- less reliable than a filesystem
The only benefit is that it can take place within a transaction but this
doesn't really help out much...
> We plug it into Jetspeed as a logical equivalent to defaultPortlets.xml. The
> only time this would be disadvantageous would be storing a setting for an
> individual portlet. We would have to write the entire record just to store one
> setting. Is that performance trade off worth making our lives a lot more
> complicated? I would say no, because I don't expect people to change
> individual settings much. I assume people will be more interested in picking
> what content they want; they may occasionally want to apply a different look,
> but once they have the look they want, I doubt they'll change it much.
-1 for storing XML in the DB right now. Not unless we can map the XML
schema out into a DB schema.
> Of course, I haven't really looked at Avalon, but that brings up another issue:
>
> I'm all for using as many different Apache projects as we can, but the barrier
> to entry on participating on this project is getting rather high.
OK. I don't want this. What can you suggest to improve what we
currently have.?
> On one hand,
> I'm super happy the apidocs are posted on Jetspeed's web site. On the other
> hand, I'm having a lot of trouble figuring out how to incorporate all these
> other projects. I knew Cocoon before I started. Turbine is just beginning
> to make sense. Jyve looks pretty straightforward but I still have to sit down
> and look at all the source code....
> Maybe what I really need is a sort of Getting Started with Jetspeed (like
> Turbine has), except more focused on what all the different packages that come
> with Jetspeed do. Maybe we could even do javadocs for all the packages in the
> distro and put em up with the Jetspeed docs.
>
> What do y'all think?
Docs are good. Maybe before the next release. Things are still up in
the air as well on certain things and once they settle down it will be
docs time again :)
Kevin
--
Kevin A Burton ([EMAIL PROTECTED])
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
"For evil to win is for good men to do nothing."
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
