I understand that protocol like http: or webdav: cannot check cache-key validity over the network.
But my understanding is slide: protocol is just a direct access to the Slide API, that in my case access the file locally on the server. So I guess the overhead is small compare to a direct file access, but maybe I'm wrong. Is there a way to force cocoon to check the cache-key validity for slide: protocol like it does for local file? Thanks and Regards, Benoit. -----Original Message----- From: Ard Schrijvers [mailto:[EMAIL PROTECTED] Sent: Friday, October 28, 2005 10:33 AM To: [email protected] Subject: RE: sitemap.xmap does not reload on slide repository This is quite complex what you want. When stored on filesystem and using something in a cached pipeline, a change of the file will invalidate the cached pipeline (do not know if this happens instantly or on requesting the pipeline again, I suppose the last). But when you are using some protocol, like slide: or an http: request, this is not possible. Think checking over http or slide: for just the cache-key is taking to long or is not possible. I am not certain about this. Anyway, the way we solve this is smart ecaching, only invalidating cache keys which should be invalidated. This happens through JMS messages. How it is used is for example as follows: We have in slide 10.000 news articles under nl/abroad/news On the website/intranet, there is a pipeline that calls for example nl/abroad/news, which fetches with a dasl (being translated into lucene search) the latest 10 articles. In the cash key, the initial part "nl/abroad/news" is taken into account. Now, when an article is added to "nl/abroad/news/2005/12", slide sents a JMS message to the right cocoon instance. The cocoon instance invalidates all the cache keys depending on "nl/abroad/news/2005/12", "nl/abroad/news/2005", "nl/abroad/news", "nl/abroad","nl". But for example the news archive of "en/abroad/news/", or "nl/abroad/agenda" will not be invalidated. Well, bottom line is that this is ofcourse quite a complex infrastructure, and probably a little bit to much for just a subsitemap. Anyway, this is how we do it.... AS > Hi, > > I'm trying to use slide repository to store a cocoon subdirectory. In > the root sitemap.xmap, I've added these lines: > > <map:match pattern="web/**"> > <map:mount check-reload="yes" src="slide://cocoon/site/sitemap.xmap" > uri-prefix="web"/> > </map:match> > > Unfortunately, when I change the slide://cocoon/site/sitemap.xmap, > cocoon does not take the changes into account, despite the > check-reload option. > I need to modify the root sitemap.xmap to take the changes into > account. > > It is a problem in cocoon caching system or in the slide API? > > Thanks in advance, > Benoit. > > --------------------------------------------------------------------- > 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]
