On 18 Nov 2003, at 03:36, Daniel Florey wrote:
[snip...]
My favorit issues are: - Getting the stores to work as expected (at least file/db-stores)
this is critical, yes.
- Implement internal locking (should not be transactional)
can you tell us more about this?
I think we need two different types of locks in slide: First there are
webdav-locks that should be acquired/released transactional. This means that
it should be possible to acquire a number of locks in one transactional and
rollback the whole transaction when a single lock fails.
Bedides this there is a need for internal global locks that handle concurrents
modifications. Think of two copy operations in different transactions where
every user wants to to copy to the same target. At the moment this is
delegated to underlying stores in a not very beatyful manner (recursive
read)...
Olli will start a thread on this to discuss this in more detail.
ok, I agree that's better to separate issues in different threads.
First and most easy would be to disable caching :-)- Improve and fix caching. It's not fully transactional in some places
and can be improved (especially lock/permission-cache)
same here, do you have any idea on how to do this? [curious]
well :-)
If caching is enabled, it must be ensured that the cache is always consistent.
yep
At the moment there a some places, where for example invalid data remains in
the cache if a transaction is rolled back (have a look at StandardStore).
ouch, didn't know that.
So the store must be transaction-aware. Olli has implemented transactional
caching in extended store, this is the way to go.
Good, so we should get rid of the stores that do not support this. Not only place them into the "attic/scratchpad" but kill them completely, or users might step into them since "StandardStore" seems to imply that's the way to go, but it's not.
But permission caching is still broken. This is not that worse, because the
cache resides in SlideToken - that means that the cache will be per user and
is getting recreated every request. This should be improved.
Oh, definately. Gosh, I need to dive deeper into slide to see how it works in these details.
I will post on this issue later. The events must be transaction aware as well- (lateron) real XA-support to use different stores (a great feature of
slide) in one transaction
ah, nice.
- Extendable event mechanism (that is essenital for 'inverted caching' in
the presentation layer or to distribute changes in a clustered
environment)
big +1, what do you have in mind for this? interceptors?
(some need to be sent after commit, some may be needed before to enable
vetoable changes).
hmmmm, synchronicity creates possible deadlocks: how would you solve the problem of a vetoable change that doesn't get vetoed nor approuved because the listener is busy, overloaded or crashed? timeouts?
There should be a number of internal events and the possibility to generate
custom events for example inside an interceptor.
In our product we used events not only for caching, but also for synchronizing
the editors swing clients by pushing events to all client. This is a very
nice feature, because the client users can see in realtime what other editors
do and navigation on the website can be synchronized with the clients
navigation.
Nice, but yeah, this is a general ability of operation observability, but I think I like passive observability more than active one. The repository is versioned and workflow issues shouldn't happen thru observability directly, but thru an application layer on top of the versioned repository.
- Implement fast searching capabilities (properties and full text search,
perhaps using lucene)
that would be cool. How pluggable is the DASL implementation?
Don't know yet. At the moment the stores are responsible for search.
I see.
There is
for example a XQuery engine in the tamino stores that can be triggered via
DASL as far as I know, but this is of course not part of slide...
of course, we wouldn't know what to do with it :-)
- Internal link checking (so that if you check out some revision of a
document that uses others you're informed and get the choice to check out
the used documents in the right revision as well). I don't know, if the
current content interceptor concept allows such a feature as an optional
module, otherwise it should be improved to allow something like this.
I would say this is application-dependent. I agree that the repository
should provide the ability to implement the above functionality, but it
should not be something that the repository gives you directly...
otherwise you blur the line between the repository and its semantics...
and this is a path I wouldn't want Slide to see going.
Agreed.
On the other hand I still won't drop my idea to donate our
rendering/process-engine (maybe into proposals-section) and implement
some demo-project to give users a better starting point and a full
featured framework to implement projects. But I see that this have to be
discussed.
I say we focus on getting the repository out solid, fast and clean, then
we'll see what happens.
Yes, but personally I'm responsible for providing a CMS product wich is used
in our company. So I have to care about the other things as well and can't
distribute that much at the moment...
While I understand your responsabilities, I don't understand what this has to do with potential contributions. Contributing a piece of code doesn't necessarely mean that a community is created around it. Actually, this very project shows how hard it is to create a community around a piece of contributed software.
And for this reason, I would start focusing and then expand the potential focus depending on the needs of the community.
[who might just welcome your contributions, I'm not saying the opposite, but currently they are definately not a priority for people interested on a content repository]
-- Stefano.
smime.p7s
Description: S/MIME cryptographic signature
