> Thank you Remi, especially for your quick response. > > You've largely answered my question, but now I have an issue with > scalability - I have had a very similar problem recently with a project > I did for a client - first thing they did was install two different web > servers (i.e. physical machines) using the same repository. Although I > was only caching schema/security info rather than content - they > immediately queried why changes made to one were not reflected in the > other (until a restart). I added an option for an administrator to > reload the cache (via a web page), which was fine for them, because > changes were rare. Obviously this techinique is of little use when we're > dealing with user content. > > This is something of a show-stopper for me. You mention you have lots of > ideas - any more info? Can I help?
Well, we "only" need a fast mechanism to access an equivalent of a timestamp for a node. There's a unique (and timestamped) id for each write operation made by Slide (that's the transaction xid). By associating the "timestamp" with the uri in a special store, we could easily do cache revalidation. Overall, there are quite a few behind-the-scene changes that could improve scalability, but it will take some time. At the moment, the focus is on building additional APIs and interfaces on top of Slide (support for more WebDAV protocols, additional features, HTML interface, ...). Remy
