Darren Hartford wrote:
Putting back at least one response from the user-standpoint versus dev
-- thank goodness for the seperation and redesign! :-D
Slide has worked great to-date, but as new requirements and new needs
came up, it has started to get a little ugly, and as anyone knows, only
a few people would want to jump into a project if the learning curve is
too high.
diving quite deep into slide, I've seen that it needs a full refactor of
project structure at first. In fact there are lots of parts that are
begun but not properly finished. For example : the lucene property
indexer is only used for your own metadatas if you modify an XML file
which is located in the code. There is no way to override this
configuration so you need to put this XML file at the same exact place
in order for the classloader to find and pray that it finds it BEFORE it
finds the one in the stores jar....
In fact, my feeling is that the kernel is still quite clean. But the
upperlying layers are a little bit messed up. In fact the layers depend
on each other which is not a good idea of course. My work has not been
to redesign the whole thing. But it may be a step towards cleaner
separations.
One point is that some utils libraries should be extracted and placed as
a separate jar.
Just a couple of thoughts as you consider the redesign -
*ConfigStore - Possibly moving the generic configuration of all the
stores (each with specific pointers/parameters/etc - like the URI and
serving-side security/ACL per store) into a single ConfigStore that is
centric to the SlideServer and not have each-store-store-its-own-config.
Would be easier for future management extensions.
You're right. There are lots of configurable elements within slide which
are most of the time not seenable by the user. Your only choice is to
dive into the code and see what the options are...
ResourceKinds.xml, defaultConfig.xml, ... the configurations are split
and it takes time to get all the pieces to understand how you can use
all this.
*Allow easy integration of existing repositories - I like that. One
use-case I've been trying to use is if using the Slide TxXmlDescriptor
and TxFileStore Stores to collect items and metadata, then taking a
snapshot/state and burn it to CD, and then trying to re-integrate it
back into the Slide server (which doesn't work as the Tx** won't work
with read-only media, and is kinda a pain working with the domain.xml to
re-integrate it back).
Again, this is just a user-perspective, but looking forward to the Slide
3.0 redesign!
-D
I've never been faced to these use cases. But sure this is true. Can't
help there.
Anyway who is the maintainer of Slide now ? I haven't seen anything
committed for several months, even if I've submitted some patches here
and there...
Regards,
Fabrice Dewasmes
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
