Menu
▾
▴
[ naviserver-Feature Requests-1159259 ] Add nscache module functionality
|
From: SourceForge.net <no...@so...> - 2005-12-30 11:09:24
|
Feature Requests item #1159259, was opened at 2005-03-08 11:30 Message generated for change (Comment added) made by sdeasey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1159259&group_id=130646 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tcl-API Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Zoran Vasiljevic (vasiljevic) Assigned to: Stephen Deasey (sdeasey) Summary: Add nscache module functionality Initial Comment: This is really what needs to be done sine the server itself does support the caches and what lacks is the Tcl access to them. The nscache module (or its equivalent) deserves to be part of the server distribution. ---------------------------------------------------------------------- >Comment By: Stephen Deasey (sdeasey) Date: 2005-12-30 04:09 Message: Logged In: YES user_id=87254 See RFE: 1119257 ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-03-18 05:15 Message: Logged In: YES user_id=95086 Take whatever time you need. I do not have any problems with that. I also think that namespaced commands are better, so instead of ns_cache blabla the better way would be ns::cache::blabla but I think it is to early to make this kind of switch. We can eventually make this sometime, leaving the ns_xxxx for compatibility, but this is another story. ---------------------------------------------------------------------- Comment By: Stephen Deasey (sdeasey) Date: 2005-03-18 05:03 Message: Logged In: YES user_id=87254 The existing nscache module is a good example of the ensemble method of command parsing sucking, IMHO. The master command has to parse the first word to figure out which subcommand to invoke, and then dispatches to the implementation of that subcommand as they have nothing in common. It requires extra code and slows performance. There are locking problems with the current API. ns_cache_stats, for example, can access any cache in the system at any time but there is no locking of the Cache structures. The built in commands work on a global level, the commands in the nscache module operate only on caches created with those commands. It would be a shame to junk the ability of the current commands to work with all caches. The nscache module works fine as is, and as I've already started work on integrating the tcl cache commands I'd prefer if the old ones weren't added in the mean time. Can you give me some time to post a patch to the original cache RFE? ---------------------------------------------------------------------- Comment By: Zoran Vasiljevic (vasiljevic) Date: 2005-03-18 01:56 Message: Logged In: YES user_id=95086 I would also somehow unify the Tcl api interface. If you look at the server part it does: ns_cache_XXXXX whereas the cache module has different api ns_cache YYYY I prefer the latter (ensemble-based) api. If we move the cache module in the core, we should make ns_cache YYYYY wrappers to do the ns_cache_XXXXX commands. What do you think? ---------------------------------------------------------------------- Comment By: Vlad Seryakov (seryakov) Date: 2005-03-17 21:33 Message: Logged In: YES user_id=184124 For a start we can just add tclcache.c into the core and leter improve/rewrite caching if needed. Currenlty i am pretty happy with this module functionality as is. ---------------------------------------------------------------------- Comment By: Vlad Seryakov (seryakov) Date: 2005-03-08 12:48 Message: Logged In: YES user_id=184124 Yes, i agree with it ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1159259&group_id=130646 |
