naviserver-devel

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Vlad S. <vl...@cr...>]

Stephen,

I understand you have the "right" vision how to do things but after long 
period of time just removing Tcl API functions (cache set/get) is not 
very polite.
It breaks a lot of Tcl code and i am not sure why do you think they are 
racey and i need to emulate them in Tcl instead of C.

Very frustrating.


Stephen Deasey wrote:
> Update of /cvsroot/naviserver/naviserver
> In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv27993
> 
> Modified Files:
> 	ChangeLog 
> Log Message:
>         * nsd/fastpath.c:
>         * nsd/adpeval.c: Use Ns_CacheDeleteEntry instead of
>         Ns_CacheFlushEntry to prevent genuine flush stats being inflated.
> 
>         * tcl/cache.tcl:
>         * nsd/nsconf.c:
>         * nsd/dns.c: Update to new API.
> 
>         * nsd/nsd.h:
>         * nsd/server.c: Remove tcl cache timeout param in anticipation of new
>         limits API.
> 
>         * nsd/tclcmds.c: Remove ns_cache _get _set _exists _info
>         commands. The first three are racey and can be emulated with _eval
>         and the new -force switch.  The new -contents switch to the _stats
>         command replaces _info, discouraging racey check-and-set usage.
> 
>         * nsd/tcltime.c:
>         * nsd/tclobjv.c: New Ns_ObjvTime parse callback for the Ns_Time
>         type. Handy for passing absolute time deadlines to routines which
>         timeout.
> 
>         * include/ns.h:
>         * nsd/cache.c: New Ns_CacheResetStats routine.
> 
>         Ns_CacheGetConfig removed -- caches are immutable; the current
>         settings can be looked up in the config file.
> 
>         Directly expire entries from within all routines which return one,
>         but but only if the value is not null, indicating no concurrent
>         update is in progress.
> 
>         Use Ns_CacheDeleteEntry to remove an entry from the cache without
>         updating the stats. Flush stats should reflect explicit flushes
>         only.
> 
>         Log stats when a cache is destroyed.
> 
>         * nsd/tclcache.c: ns_cache_create now takes a -maxentry option
>         which is the maximum size of an entry allowed in the cache. This
>         prevents one large entry completely emptying an otherwise usefully
>         full cache.
> 
>         The ns_cache_create -timeout switch has been removed in
>         anticipation of a general purpose limits scheme.
> 
>         The -timeout option is now expected to be an absolute time in the
>         future, not an offset from the current time. This is awkward to
>         use manually, but should not be needed with the above mentioned
>         limits scheme. The -ttl option has been renames -expires and is
>         also an absolute time.
> 
>         ns_cache_eval now takes a -force switch which will unconditioanly
>         replace any exiting entry, whether it has expired or not. Replaces
>         _set.
> 
>         ns_cache_stats -content dumps the size and expirey for each
>         entry in the cache. Adding the -reset switch to either mode resets
>         the stats to zero.
> 
>         * tests/ns_cache.test: Try to exercise the underlying Ns_CacheFind
>         harder with some more flush tests.
> 
> 
> 
> Index: ChangeLog
> ===================================================================
> RCS file: /cvsroot/naviserver/naviserver/ChangeLog,v
> retrieving revision 1.405
> retrieving revision 1.406
> diff -C2 -d -r1.405 -r1.406
> *** ChangeLog	19 Jun 2006 19:05:47 -0000	1.405
> --- ChangeLog	19 Jun 2006 21:16:38 -0000	1.406
> ***************
> *** 1,2 ****
> --- 1,71 ----
> + 2006-06-19  Stephen Deasey  <sd...@us...>
> + 
> + 	* nsd/fastpath.c:
> + 	* nsd/adpeval.c: Use Ns_CacheDeleteEntry instead of
> + 	Ns_CacheFlushEntry to prevent genuine flush stats being inflated.
> + 
> + 	* tcl/cache.tcl:
> + 	* nsd/nsconf.c:
> + 	* nsd/dns.c: Update to new API.
> + 
> + 	* nsd/nsd.h:
> + 	* nsd/server.c: Remove tcl cache timeout param in anticipation of new
> + 	limits API.
> + 
> + 	* nsd/tclcmds.c: Remove ns_cache _get _set _exists _info
> + 	commands. The first three are racey and can be emulated with _eval
> + 	and the new -force switch.  The new -contents switch to the _stats
> + 	command replaces _info, discouraging racey check-and-set usage.
> + 
> + 	* nsd/tcltime.c:
> + 	* nsd/tclobjv.c: New Ns_ObjvTime parse callback for the Ns_Time
> + 	type. Handy for passing absolute time deadlines to routines which
> + 	timeout.
> + 
> + 	* include/ns.h:
> + 	* nsd/cache.c: New Ns_CacheResetStats routine.
> + 
> + 	Ns_CacheGetConfig removed -- caches are immutable; the current
> + 	settings can be looked up in the config file.
> + 
> + 	Directly expire entries from within all routines which return one,
> + 	but but only if the value is not null, indicating no concurrent
> + 	update is in progress.
> + 
> + 	Use Ns_CacheDeleteEntry to remove an entry from the cache without
> + 	updating the stats. Flush stats should reflect explicit flushes
> + 	only.
> + 
> + 	Log stats when a cache is destroyed.
> + 
> + 	* nsd/tclcache.c: ns_cache_create now takes a -maxentry option
> + 	which is the maximum size of an entry allowed in the cache. This
> + 	prevents one large entry completely emptying an otherwise usefully
> + 	full cache.
> + 
> + 	The ns_cache_create -timeout switch has been removed in
> + 	anticipation of a general purpose limits scheme.
> + 
> + 	The -timeout option is now expected to be an absolute time in the
> + 	future, not an offset from the current time. This is awkward to
> + 	use manually, but should not be needed with the above mentioned
> + 	limits scheme. The -ttl option has been renames -expires and is
> + 	also an absolute time.
> + 
> + 	ns_cache_eval now takes a -force switch which will unconditioanly
> + 	replace any exiting entry, whether it has expired or not. Replaces
> + 	_set.
> + 
> + 	ns_cache_stats -content dumps the size and expirey for each
> + 	entry in the cache. Adding the -reset switch to either mode resets
> + 	the stats to zero.
> + 
> + 	
> + 
> + 	
> + 
> + 	* tests/ns_cache.test: Try to exercise the underlying Ns_CacheFind
> + 	harder with some more flush tests.
> + 
>   2006-05-19  Vlad Seryakov  <ser...@us...>
>   
> 
> 
> 
> _______________________________________________
> naviserver-commits mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-commits
> 

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Vlad S. <vl...@cr...>]

Also, what is wrong with per-cache expiration policy, nc_cache_create 
-timeout parameter.
How i can create 2 caches with different expiration settings?

 >Ns_CacheGetConfig removed -- caches are immutable; the current
 > settings can be looked up in the config file.

This is not absolutely true if nothing in the config and i need to find 
out default compiled-in value. GetConfig gives runtime value regardless 
of what is set or not set in the config file. With per-cache timeout 
this makes sense. How limits are supposed to work?

Stephen Deasey wrote:
> Update of /cvsroot/naviserver/naviserver
> In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv27993
> 
> Modified Files:
> 	ChangeLog 
> Log Message:
>         * nsd/fastpath.c:
>         * nsd/adpeval.c: Use Ns_CacheDeleteEntry instead of
>         Ns_CacheFlushEntry to prevent genuine flush stats being inflated.
> 
>         * tcl/cache.tcl:
>         * nsd/nsconf.c:
>         * nsd/dns.c: Update to new API.
> 
>         * nsd/nsd.h:
>         * nsd/server.c: Remove tcl cache timeout param in anticipation of new
>         limits API.
> 
>         * nsd/tclcmds.c: Remove ns_cache _get _set _exists _info
>         commands. The first three are racey and can be emulated with _eval
>         and the new -force switch.  The new -contents switch to the _stats
>         command replaces _info, discouraging racey check-and-set usage.
> 
>         * nsd/tcltime.c:
>         * nsd/tclobjv.c: New Ns_ObjvTime parse callback for the Ns_Time
>         type. Handy for passing absolute time deadlines to routines which
>         timeout.
> 
>         * include/ns.h:
>         * nsd/cache.c: New Ns_CacheResetStats routine.
> 
>         Ns_CacheGetConfig removed -- caches are immutable; the current
>         settings can be looked up in the config file.
> 
>         Directly expire entries from within all routines which return one,
>         but but only if the value is not null, indicating no concurrent
>         update is in progress.
> 
>         Use Ns_CacheDeleteEntry to remove an entry from the cache without
>         updating the stats. Flush stats should reflect explicit flushes
>         only.
> 
>         Log stats when a cache is destroyed.
> 
>         * nsd/tclcache.c: ns_cache_create now takes a -maxentry option
>         which is the maximum size of an entry allowed in the cache. This
>         prevents one large entry completely emptying an otherwise usefully
>         full cache.
> 
>         The ns_cache_create -timeout switch has been removed in
>         anticipation of a general purpose limits scheme.
> 
>         The -timeout option is now expected to be an absolute time in the
>         future, not an offset from the current time. This is awkward to
>         use manually, but should not be needed with the above mentioned
>         limits scheme. The -ttl option has been renames -expires and is
>         also an absolute time.
> 
>         ns_cache_eval now takes a -force switch which will unconditioanly
>         replace any exiting entry, whether it has expired or not. Replaces
>         _set.
> 
>         ns_cache_stats -content dumps the size and expirey for each
>         entry in the cache. Adding the -reset switch to either mode resets
>         the stats to zero.
> 
>         * tests/ns_cache.test: Try to exercise the underlying Ns_CacheFind
>         harder with some more flush tests.
> 
> 
> 
> Index: ChangeLog
> ===================================================================
> RCS file: /cvsroot/naviserver/naviserver/ChangeLog,v
> retrieving revision 1.405
> retrieving revision 1.406
> diff -C2 -d -r1.405 -r1.406
> *** ChangeLog	19 Jun 2006 19:05:47 -0000	1.405
> --- ChangeLog	19 Jun 2006 21:16:38 -0000	1.406
> ***************
> *** 1,2 ****
> --- 1,71 ----
> + 2006-06-19  Stephen Deasey  <sd...@us...>
> + 
> + 	* nsd/fastpath.c:
> + 	* nsd/adpeval.c: Use Ns_CacheDeleteEntry instead of
> + 	Ns_CacheFlushEntry to prevent genuine flush stats being inflated.
> + 
> + 	* tcl/cache.tcl:
> + 	* nsd/nsconf.c:
> + 	* nsd/dns.c: Update to new API.
> + 
> + 	* nsd/nsd.h:
> + 	* nsd/server.c: Remove tcl cache timeout param in anticipation of new
> + 	limits API.
> + 
> + 	* nsd/tclcmds.c: Remove ns_cache _get _set _exists _info
> + 	commands. The first three are racey and can be emulated with _eval
> + 	and the new -force switch.  The new -contents switch to the _stats
> + 	command replaces _info, discouraging racey check-and-set usage.
> + 
> + 	* nsd/tcltime.c:
> + 	* nsd/tclobjv.c: New Ns_ObjvTime parse callback for the Ns_Time
> + 	type. Handy for passing absolute time deadlines to routines which
> + 	timeout.
> + 
> + 	* include/ns.h:
> + 	* nsd/cache.c: New Ns_CacheResetStats routine.
> + 
> + 	Ns_CacheGetConfig removed -- caches are immutable; the current
> + 	settings can be looked up in the config file.
> + 
> + 	Directly expire entries from within all routines which return one,
> + 	but but only if the value is not null, indicating no concurrent
> + 	update is in progress.
> + 
> + 	Use Ns_CacheDeleteEntry to remove an entry from the cache without
> + 	updating the stats. Flush stats should reflect explicit flushes
> + 	only.
> + 
> + 	Log stats when a cache is destroyed.
> + 
> + 	* nsd/tclcache.c: ns_cache_create now takes a -maxentry option
> + 	which is the maximum size of an entry allowed in the cache. This
> + 	prevents one large entry completely emptying an otherwise usefully
> + 	full cache.
> + 
> + 	The ns_cache_create -timeout switch has been removed in
> + 	anticipation of a general purpose limits scheme.
> + 
> + 	The -timeout option is now expected to be an absolute time in the
> + 	future, not an offset from the current time. This is awkward to
> + 	use manually, but should not be needed with the above mentioned
> + 	limits scheme. The -ttl option has been renames -expires and is
> + 	also an absolute time.
> + 
> + 	ns_cache_eval now takes a -force switch which will unconditioanly
> + 	replace any exiting entry, whether it has expired or not. Replaces
> + 	_set.
> + 
> + 	ns_cache_stats -content dumps the size and expirey for each
> + 	entry in the cache. Adding the -reset switch to either mode resets
> + 	the stats to zero.
> + 
> + 	
> + 
> + 	
> + 
> + 	* tests/ns_cache.test: Try to exercise the underlying Ns_CacheFind
> + 	harder with some more flush tests.
> + 
>   2006-05-19  Vlad Seryakov  <ser...@us...>
>   
> 
> 
> 
> _______________________________________________
> naviserver-commits mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-commits
> 

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Stephen D. <sd...@gm...>]

On 6/19/06, Vlad Seryakov <vl...@cr...> wrote:
> Also, what is wrong with per-cache expiration policy, nc_cache_create
> -timeout parameter.
> How i can create 2 caches with different expiration settings?


Nothing particularly, but there's a better way to do it:

Look at the aolserver head, at nsd/limits.c.  A 'limits' is a
collection of setting such as max upload size, timeout etc.  You
create one or more of these then bind them to a URL, just like
ns_register_proc.

The timeout in the aolserver implementation refers to just the time
waiting for a conn thread.  I'm going to extend that to mean total
time allowed for the conn to run.

So, you might set timeout to be 30 seconds.  You bind this to /*, i.e.
every URL.  Now, when you use a cache, or ns_proxy, or ns_db, or in
fact anything where a timeout is needed, and you haven't specified
anything expliciltly using a  -timeout switch, the limits are used.

This is actually more what you want -- you're defining the quality of
service you expect to give.  I made some changes recently so that Tcl
code which times out in this way throws a particular error code. This
is picked up by the server and turned into the appropriate HTTP
'server busy' code.

To get this working, Ns_Conn structs need to be allocated in driver.c,
not queue.c as they are now.  driver.c is looking a little scary...



>  >Ns_CacheGetConfig removed -- caches are immutable; the current
>  > settings can be looked up in the config file.
>
> This is not absolutely true if nothing in the config and i need to find
> out default compiled-in value. GetConfig gives runtime value regardless
> of what is set or not set in the config file. With per-cache timeout
> this makes sense. How limits are supposed to work?


Don't compile in defaults, use Ns_ConfigGet* etc.


> Stephen Deasey wrote:
> > Update of /cvsroot/naviserver/naviserver
> > In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv27993
> >
> > Modified Files:
> >       ChangeLog
> > Log Message:
> >         * nsd/fastpath.c:
> >         * nsd/adpeval.c: Use Ns_CacheDeleteEntry instead of
> >         Ns_CacheFlushEntry to prevent genuine flush stats being inflated.
> >
> >         * tcl/cache.tcl:
> >         * nsd/nsconf.c:
> >         * nsd/dns.c: Update to new API.
> >
> >         * nsd/nsd.h:
> >         * nsd/server.c: Remove tcl cache timeout param in anticipation of new
> >         limits API.
> >
> >         * nsd/tclcmds.c: Remove ns_cache _get _set _exists _info
> >         commands. The first three are racey and can be emulated with _eval
> >         and the new -force switch.  The new -contents switch to the _stats
> >         command replaces _info, discouraging racey check-and-set usage.
> >
> >         * nsd/tcltime.c:
> >         * nsd/tclobjv.c: New Ns_ObjvTime parse callback for the Ns_Time
> >         type. Handy for passing absolute time deadlines to routines which
> >         timeout.
> >
> >         * include/ns.h:
> >         * nsd/cache.c: New Ns_CacheResetStats routine.
> >
> >         Ns_CacheGetConfig removed -- caches are immutable; the current
> >         settings can be looked up in the config file.
> >
> >         Directly expire entries from within all routines which return one,
> >         but but only if the value is not null, indicating no concurrent
> >         update is in progress.
> >
> >         Use Ns_CacheDeleteEntry to remove an entry from the cache without
> >         updating the stats. Flush stats should reflect explicit flushes
> >         only.
> >
> >         Log stats when a cache is destroyed.
> >
> >         * nsd/tclcache.c: ns_cache_create now takes a -maxentry option
> >         which is the maximum size of an entry allowed in the cache. This
> >         prevents one large entry completely emptying an otherwise usefully
> >         full cache.
> >
> >         The ns_cache_create -timeout switch has been removed in
> >         anticipation of a general purpose limits scheme.
> >
> >         The -timeout option is now expected to be an absolute time in the
> >         future, not an offset from the current time. This is awkward to
> >         use manually, but should not be needed with the above mentioned
> >         limits scheme. The -ttl option has been renames -expires and is
> >         also an absolute time.
> >
> >         ns_cache_eval now takes a -force switch which will unconditioanly
> >         replace any exiting entry, whether it has expired or not. Replaces
> >         _set.
> >
> >         ns_cache_stats -content dumps the size and expirey for each
> >         entry in the cache. Adding the -reset switch to either mode resets
> >         the stats to zero.
> >
> >         * tests/ns_cache.test: Try to exercise the underlying Ns_CacheFind
> >         harder with some more flush tests.
> >
> >
> >
> > Index: ChangeLog
> > ===================================================================
> > RCS file: /cvsroot/naviserver/naviserver/ChangeLog,v
> > retrieving revision 1.405
> > retrieving revision 1.406
> > diff -C2 -d -r1.405 -r1.406
> > *** ChangeLog 19 Jun 2006 19:05:47 -0000      1.405
> > --- ChangeLog 19 Jun 2006 21:16:38 -0000      1.406
> > ***************
> > *** 1,2 ****
> > --- 1,71 ----
> > + 2006-06-19  Stephen Deasey  <sd...@us...>
> > +
> > +     * nsd/fastpath.c:
> > +     * nsd/adpeval.c: Use Ns_CacheDeleteEntry instead of
> > +     Ns_CacheFlushEntry to prevent genuine flush stats being inflated.
> > +
> > +     * tcl/cache.tcl:
> > +     * nsd/nsconf.c:
> > +     * nsd/dns.c: Update to new API.
> > +
> > +     * nsd/nsd.h:
> > +     * nsd/server.c: Remove tcl cache timeout param in anticipation of new
> > +     limits API.
> > +
> > +     * nsd/tclcmds.c: Remove ns_cache _get _set _exists _info
> > +     commands. The first three are racey and can be emulated with _eval
> > +     and the new -force switch.  The new -contents switch to the _stats
> > +     command replaces _info, discouraging racey check-and-set usage.
> > +
> > +     * nsd/tcltime.c:
> > +     * nsd/tclobjv.c: New Ns_ObjvTime parse callback for the Ns_Time
> > +     type. Handy for passing absolute time deadlines to routines which
> > +     timeout.
> > +
> > +     * include/ns.h:
> > +     * nsd/cache.c: New Ns_CacheResetStats routine.
> > +
> > +     Ns_CacheGetConfig removed -- caches are immutable; the current
> > +     settings can be looked up in the config file.
> > +
> > +     Directly expire entries from within all routines which return one,
> > +     but but only if the value is not null, indicating no concurrent
> > +     update is in progress.
> > +
> > +     Use Ns_CacheDeleteEntry to remove an entry from the cache without
> > +     updating the stats. Flush stats should reflect explicit flushes
> > +     only.
> > +
> > +     Log stats when a cache is destroyed.
> > +
> > +     * nsd/tclcache.c: ns_cache_create now takes a -maxentry option
> > +     which is the maximum size of an entry allowed in the cache. This
> > +     prevents one large entry completely emptying an otherwise usefully
> > +     full cache.
> > +
> > +     The ns_cache_create -timeout switch has been removed in
> > +     anticipation of a general purpose limits scheme.
> > +
> > +     The -timeout option is now expected to be an absolute time in the
> > +     future, not an offset from the current time. This is awkward to
> > +     use manually, but should not be needed with the above mentioned
> > +     limits scheme. The -ttl option has been renames -expires and is
> > +     also an absolute time.
> > +
> > +     ns_cache_eval now takes a -force switch which will unconditioanly
> > +     replace any exiting entry, whether it has expired or not. Replaces
> > +     _set.
> > +
> > +     ns_cache_stats -content dumps the size and expirey for each
> > +     entry in the cache. Adding the -reset switch to either mode resets
> > +     the stats to zero.
> > +
> > +
> > +
> > +
> > +
> > +     * tests/ns_cache.test: Try to exercise the underlying Ns_CacheFind
> > +     harder with some more flush tests.
> > +
> >   2006-05-19  Vlad Seryakov  <ser...@us...>
> >
> >
> >
> >
> > _______________________________________________
> > naviserver-commits mailing list
> > nav...@li...
> > https://lists.sourceforge.net/lists/listinfo/naviserver-commits
> >
>
> --
> Vlad Seryakov
> 571 262-8608 office
> vl...@cr...
> http://www.crystalballinc.com/vlad/
>
>
>
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Vlad S. <vl...@cr...>]

> Nothing particularly, but there's a better way to do it:


There are multiple ways to do it but it does not mean that server should 
allow only one way for developer. This is the reason why projects fork, 
if it is not flexible enough and not willing to be extended enough.

 >
>Look at the aolserver head, at nsd/limits.c.  A 'limits' is a
>collection of setting such as max upload size, timeout etc.  You
>create one or more of these then bind them to a URL, just like
>ns_register_proc.


May be limits is a good idea for Url based requests but for server side 
applications how i am supposed to use ns_cache with different timeout 
settings, Do not tell me emulate this via url procs. Cache is generic 
API which should not be bound to URL processing at all. AOLserver does 
it but it looks like the aolserver server is dedicated for URL 
processing only, as webserver only, that was the reason of forking to 
make naviserver more generic and feature-full. I will not agree to 
follow Aolserver path.


PS: Also, if you are not be at the computer for along time do not commit 
big patches or big changes, now everybody is waiting for you even to 
discuss things and we are all stuck.

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Vlad S. <vl...@cr...>]

> We talked about this before.  If I remember correctly, you didn't
> disagree with me that the commands were racy, you said you code base
> was large and you didn't have time to figure out what you really
> needed.
> More and more unnecessary code is being added.  Things are getting out
> of control.  However, you'll notice that I did not just remove
> everything.  With the new -force switch to ns_cache_eval, _set, _get,
> and _info can be trivially emulated in a couple of lines of Tcl, if
> you want that kind of racy behaviour.

> Everything is of course still available via the C api, and I'd
> recommend taking a look at what your real requirements are and
> building accordingly.  If it can be generalised, we can get it into
> the core.
> 
> The timeout in the aolserver implementation refers to just the time
> waiting for a conn thread.  I'm going to extend that to mean total
> time allowed for the conn to run.
> 
> To get this working, Ns_Conn structs need to be allocated in driver.c,
> not queue.c as they are now.  driver.c is looking a little scary...
> 

By reading this i got an impression that i should expect in the future 
one day that CVS HEAD is completely re-written, all parts that you think 
are
unnecessary or not correspond to your requirements are removed. And this 
can happen even without warning. Looks like you have big plans for all 
parts already. You should have asked us before removing parts that are 
in the source for several months already.

I would suggest for all of us to define how we do development and 
respect each others rights and ability to extend server.

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Zoran V. <zv...@ar...>]

Am 21.06.2006 um 20:06 schrieb Vlad Seryakov:

>
> By reading this i got an impression that i should expect in the future
> one day that CVS HEAD is completely re-written, all parts that you  
> think
> are
> unnecessary or not correspond to your requirements are removed. And  
> this
> can happen even without warning. Looks like you have big plans for all
> parts already. You should have asked us before removing parts that are
> in the source for several months already.
>
> I would suggest for all of us to define how we do development and
> respect each others rights and ability to extend server.

Slowly, slowly...

The fact that Stephen has plans and ideas is the *best* that we can get!
You also contribute *a lot* and all is going fine actually!
This is the motor. So we should keep that motor running under all
circumstances! What you are suggesting, I believe, is to keep the power
"controllable" and I'm sure everybody thinks the same way.

I love to see additions/alternations of the existing code. If nothing
changes then everbody looses. What I would only require from anybody
contributing his valuable time and knowledge to the project is to be
little bit more *expressive* in terms of communicating what/when/why...

I personally do not care if the entire code is rewriten upside down
as long as it serves the purpose.

Cheers,
Zoran

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Stephen D. <sd...@gm...>]

On 6/21/06, Vlad Seryakov <vl...@cr...> wrote:
> > We talked about this before.  If I remember correctly, you didn't
> > disagree with me that the commands were racy, you said you code base
> > was large and you didn't have time to figure out what you really
> > needed.
> > More and more unnecessary code is being added.  Things are getting out
> > of control.  However, you'll notice that I did not just remove
> > everything.  With the new -force switch to ns_cache_eval, _set, _get,
> > and _info can be trivially emulated in a couple of lines of Tcl, if
> > you want that kind of racy behaviour.
>
> > Everything is of course still available via the C api, and I'd
> > recommend taking a look at what your real requirements are and
> > building accordingly.  If it can be generalised, we can get it into
> > the core.
> >
> > The timeout in the aolserver implementation refers to just the time
> > waiting for a conn thread.  I'm going to extend that to mean total
> > time allowed for the conn to run.
> >
> > To get this working, Ns_Conn structs need to be allocated in driver.c,
> > not queue.c as they are now.  driver.c is looking a little scary...
> >
>
> By reading this i got an impression that i should expect in the future
> one day that CVS HEAD is completely re-written, all parts that you think
> are
> unnecessary or not correspond to your requirements are removed. And this
> can happen even without warning. Looks like you have big plans for all
> parts already. You should have asked us before removing parts that are
> in the source for several months already.
>
> I would suggest for all of us to define how we do development and
> respect each others rights and ability to extend server.
>


Adding without restraint is also a problem.  It gets to the point
where you code yourself to a stand still.  For example, there are some
long standing bugs in the driver code which have been looked at and
are still failing tests.  Essentially, they are unfixable.

Here's a recent example:

The routine Ns_SockTimeWait was changed so that if NULL is passed as
the timeout, it just polls.  All the other calls in the server which
take a timeout parameter, NULL mean infinite wait, not no wait.

If you look at the context in which this is used, SockTimedWait is
used to ask the question "is this socket writeable?".  There is no
wait, for any amount of time.  It makes the code very hard to read,
especially in combination with similar changes.



.

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Vlad S. <vl...@cr...>]

> 
> Adding without restraint is also a problem.  It gets to the point
> where you code yourself to a stand still.  For example, there are some
> long standing bugs in the driver code which have been looked at and
> are still failing tests.  Essentially, they are unfixable.

We discussed driver extensions and i offered more than year ago what 
could work and it is working fine, i've been using that extensions all 
the time and now. We agreed until something better will appear i will 
keep this driver code. As for failing tests, in real life the code works 
but with this tests not so it is still unclear why. I use upload/writer 
threads in pretty busy environment so it is not completely bad but 
again, do not just wipe them out, let's discuss what you can offer 
instead of this keeping the functionality of course.

> Here's a recent example:
> 
> The routine Ns_SockTimeWait was changed so that if NULL is passed as
> the timeout, it just polls.  All the other calls in the server which
> take a timeout parameter, NULL mean infinite wait, not no wait.
> 
> If you look at the context in which this is used, SockTimedWait is
> used to ask the question "is this socket writeable?".  There is no
> wait, for any amount of time.  It makes the code very hard to read,
> especially in combination with similar changes.

I checked the code and previously Ns_SockTimeWait could not accept NULL, 
it assumed that it is always passed, so adding NULL was safe, but i 
agree, passing 0 timeout would do the same purpose and adding NULL as 
infinite would be more logical.

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Zoran V. <zv...@ar...>]

Am 21.06.2006 um 19:01 schrieb Stephen Deasey:

> Look at the aolserver head, at nsd/limits.c.  A 'limits' is a
> collection of setting such as max upload size, timeout etc.  You
> create one or more of these then bind them to a URL, just like
> ns_register_proc.

But Stepehn, lets look this from another perspective...

We use NS to about 80-85% as a general purpose application
server and to the rest as webserver. For us, binding a
limit to an URL does not mean much. Instead we have divided
our code in multiple C and Tcl modules we plug into the server
and each module has its own configuration section where we draw
defaults/limits etc, falling back to defaults built into the server.

WFor example, we use -timoeut option for generating cache to be
able to create a cache per-module with per-module defaults.
This is of course different for every module. How are we to solve
this with the scheme you are proposing or with the a'la AOLserver
limits infrastructure (per URL based) ???
Can we "bind" those limits to whatever we want? How is this working
in detail? Do you have a executive summary (in a nutshell) for me
or do I have to go to AS sources and learn all that from there?

Cheers,
Zoran

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Stephen D. <sd...@gm...>]

On 6/22/06, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 21.06.2006 um 19:01 schrieb Stephen Deasey:
>
> > Look at the aolserver head, at nsd/limits.c.  A 'limits' is a
> > collection of setting such as max upload size, timeout etc.  You
> > create one or more of these then bind them to a URL, just like
> > ns_register_proc.
>
> But Stepehn, lets look this from another perspective...
>
> We use NS to about 80-85% as a general purpose application
> server and to the rest as webserver. For us, binding a
> limit to an URL does not mean much. Instead we have divided
> our code in multiple C and Tcl modules we plug into the server
> and each module has its own configuration section where we draw
> defaults/limits etc, falling back to defaults built into the server.
>
> WFor example, we use -timoeut option for generating cache to be
> able to create a cache per-module with per-module defaults.
> This is of course different for every module. How are we to solve
> this with the scheme you are proposing or with the a'la AOLserver
> limits infrastructure (per URL based) ???
> Can we "bind" those limits to whatever we want? How is this working
> in detail? Do you have a executive summary (in a nutshell) for me
> or do I have to go to AS sources and learn all that from there?


You chopped out the description from your quote above  :-)

The idea is to use the idea of 'limits', as aolserver does, but to use
the timeout limit in a broader way.

The aolserver timeout limit refers only to the amount of time
connections spend waiting for conn threads before being dropped.  The
idea here is to extend that and say the timeout is the total amount of
time the connection should spend running.

A single page request can often have more than one call to ns_cache_,
ns_httpget, ns_prcxy, ns_job, and so on.  You can set the timeout for
each call to ns_cache to be 30 seconds.  If the first call completes
immediately, but the second takes 31 seconds, your page fails.
However, by definition you were quite prepared to wait 58 seconds for
the page to complete.

When a connection is accepted the time is logged.  Depending on the
URL, a particular limit is selected, say 30 seconds.  This is added to
the accept time to get a time in the future beyond which you're not
prepared to wait on a condition variable used by any of the calls
mentioned above.

You mentioned modules with different timeout values.  It depends how
you use them.  If your accessing a cache from a scheduled proc, then
you don't have a URL to get a limit, so perhaps you want some
per-cache settings.  I guess you might insist that even with the URL
limit available, one cache absolutely needs to wait significantly
longer than another and you're prepared to accept the limitations
mentioned above that happen when you add a series of timeouts
together.

Either way, per-cache timeouts seem reasonable.  But this is a Tcl
thing.  There's a new Tcl cache structure for storing this info.  Tcl
and C are so different that it's just a limitation to force this into
the C cache routines.

Here's a question though: if you have URL limits and per cache limits,
which takes precedence?

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Zoran V. <zv...@ar...>]

Am 25.06.2006 um 14:57 schrieb Stephen Deasey:

>
> Here's a question though: if you have URL limits and per cache limits,
> which takes precedence?

Good question!

As I'm reading your response I now get the idea where you're
heading. This makes much sense if you have a very clear idea
what your "job" is.

In the case of fetching a dynamic page, the "job" is clear:
it is the time between the start of request and the time
when the last byte of the page is returned. This is more-less
the main job of an web-server.

But in the case of an arbitratry call to some long-running
procedure, as in application server(s), things become complicated
as "job" is difficult to define. You can think of a job as a
procedure call or call to a predefined sequences of procedures,
or... what??

Take for example our application which uses NS as a general
purpose application server. It starts a "job" of saving couple
of TB of user data on some tape media. Underneath this is just
a procedure call. But inside, we start numerous threads, call
100's of internal subprocedures, do socket comm to several
other instances of NS running on other hosts etc...
We use all sorts of internal timeouts there. Yet, we do not try
to sum them all and project a time in future when a "job" should
finish! We do not know when that will be, as million things can
come in between. I will not go into more detail because I'm sure
you understand what I mean.

I must say that I will have to re-think twice or more the idea
you are proposing and see how this will affect us, as this is
not trivial. And it is not compatible to any code we have running
now. The idea itself seems very appealing but I have headaches
when I start to think about implications... :-(

Cheers
Zoran

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Vlad S. <vl...@cr...>]

To mimic Tcl variables usage or any memory access operations, by having 
_set, _get, _exist, _unset with additional _eval will make it complete 
and will allow to use by the developer as he sees fit. These are basic 
operations, on top of that a developer can build different systems, not 
just one way. It is development tool, not complete system, we can never 
anticipate all possible usages of cache API, so providing low-level 
primitives in my opinion is good direction.

> 
> But, do not get me wrong. I'm not in favour of stripping functionality.
> As far as I', concerned, ns_cache API can consist of only three
> calls:
> 
>     ns_cache_create
>     ns_cache_eval
>     ns_cache_flush
> 
> More is not needed for the "usual" cache operation. Now, one
> can imagine adding some operations on the cache vaules directly
> like
> 
>     incr
>     llength
>     lindex
> 
> and atomic operations lile
> 
>     set
>     exists
>     get
> 
> which is all allright but in some "sense" diverts from the
> base idea of cache: just temporary store values resulting
> from hard caclulations.


Tcl variable fall into this category as well and has more operations and 
other tools to work with. Why limiting cache, in some sens it is shared 
variables by more than one thread with locking, expiration if set, and 
timeouts if set. what is wrong to treat cache as more powerfull tool.


-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Zoran V. <zv...@ar...>]

Am 30.06.2006 um 19:50 schrieb Vlad Seryakov:

> To mimic Tcl variables usage or any memory access operations, by  
> having
> _set, _get, _exist, _unset with additional _eval will make it complete
> and will allow to use by the developer as he sees fit. These are basic
> operations, on top of that a developer can build different systems,  
> not
> just one way. It is development tool, not complete system, we can  
> never
> anticipate all possible usages of cache API, so providing low-level
> primitives in my opinion is good direction.

Be it. I do not have anything against. Developers should be warned
though that exists/get or exists/set or any combianation of those
must be protected by external mutex to avoid race conditions.
In that case, one should/would add something like:

   ns_cache_lock cachename {
      do whatever with the cache
   }

which needs to be a recursive lock, OR

   ns_cache_lock cachename
   ns_cache_unlock cachename

in which case developer should exercise caution
to make sure to unlock the cache at all costs even
in case of Tcl error happening between lock/unlock calls.

So. This is what I must add to it.

Cheers,
Zoran

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Vlad S. <vl...@cr...>]

> 
> Be it. I do not have anything against. Developers should be warned
> though that exists/get or exists/set or any combianation of those
> must be protected by external mutex to avoid race conditions.
> In that case, one should/would add something like:
> 
>    ns_cache_lock cachename {
>       do whatever with the cache
>    }

This is ns_cache_eval

> which needs to be a recursive lock, OR
> 
>    ns_cache_lock cachename
>    ns_cache_unlock cachename
> 
> in which case developer should exercise caution
> to make sure to unlock the cache at all costs even
> in case of Tcl error happening between lock/unlock calls.
> 
> So. This is what I must add to it.

It is not necessary, we have ns_cache_eval to such things.

_set will do it with locking, _get will return consistent value as well. 
The only place when it needs when somebody will do
if { ns_cache_exist cache key] } {
   ...
   ns_cache_....
   ...
}

But again, it could perfectly correct in his case if cache entry never 
got flushed, but system need to act on his appearance, so check for 
existence will notify caller that he may do some thing already, so i 
would let developer decide, but putting notes in the docs would be of 
course helpful for someone who just started learning programming with 
threads and locks.

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Zoran V. <zv...@ar...>]

Am 30.06.2006 um 21:10 schrieb Vlad Seryakov:

> It is not necessary, we have ns_cache_eval to such things.

Well. I *know* that. But the explicite lock is *needed* if
you plan to use exists/set etc... So either you must create
and use external ns_mutex or you use ns_cache_lock. Or go and debug
for ages because of the race condition possible if you do not
use it.

Cheers
Zoran

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Vlad S. <vl...@cr...>]

right

Zoran Vasiljevic wrote:
> Am 30.06.2006 um 21:10 schrieb Vlad Seryakov:
> 
>> It is not necessary, we have ns_cache_eval to such things.
> 
> Well. I *know* that. But the explicite lock is *needed* if
> you plan to use exists/set etc... So either you must create
> and use external ns_mutex or you use ns_cache_lock. Or go and debug
> for ages because of the race condition possible if you do not
> use it.
> 
> Cheers
> Zoran
> 
> 
> 
> 
> 
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] Cache comands (Was: [naviserver-commits] naviserver ChangeLog, 1.405, 1.406)

[Gustaf N. <ne...@wu...>]

Zoran Vasiljevic schrieb:
> For my *personal* taste, the API is way too large
> but what I do not use, I do not care for.
> I have nothing against having all this in core
> and I have nothing against maintaining this
> code in future, if the need arises.
>
>   
The ns_cache interface resembles much similarity to the nsv interface. 
Essentially, it looks to me
as an outsider that the main difference to nsv are the options for pool 
size and timeout. Has anyone
considered to converge nsv and ns_cache by e.g. providing storage pools 
with size and timeout
to nsv (binding nsv varnames to storage pools)?  Also, the eval 
subcommand makes sense for
nsv.

-gustaf

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Stephen D. <sd...@gm...>]

On 6/30/06, Vlad Seryakov <vl...@cr...> wrote:
> To mimic Tcl variables usage or any memory access operations, by having
> _set, _get, _exist, _unset with additional _eval will make it complete
> and will allow to use by the developer as he sees fit. These are basic
> operations, on top of that a developer can build different systems, not
> just one way. It is development tool, not complete system, we can never
> anticipate all possible usages of cache API, so providing low-level
> primitives in my opinion is good direction.


_set, _get and _exists aren't cache primitives because they're not
thread safe.


> >
> > But, do not get me wrong. I'm not in favour of stripping functionality.
> > As far as I', concerned, ns_cache API can consist of only three
> > calls:
> >
> >     ns_cache_create
> >     ns_cache_eval
> >     ns_cache_flush
> >
> > More is not needed for the "usual" cache operation. Now, one
> > can imagine adding some operations on the cache vaules directly
> > like
> >
> >     incr
> >     llength
> >     lindex
> >
> > and atomic operations lile
> >
> >     set
> >     exists
> >     get


These aren't atomic.

For example, after ns_cache_exists returns the value may exist or not
due to cache flush, expiry, etc., you really don't know.


> > which is all allright but in some "sense" diverts from the
> > base idea of cache: just temporary store values resulting
> > from hard caclulations.
>
>
> Tcl variable fall into this category as well and has more operations and
> other tools to work with. Why limiting cache, in some sens it is shared
> variables by more than one thread with locking, expiration if set, and
> timeouts if set. what is wrong to treat cache as more powerfull tool.


Tcl variables work in a completely different environment, they are not
intended to be thread safe.

[naviserver-devel] Cache comands (Was: [naviserver-commits] naviserver ChangeLog, 1.405, 1.406)

[Zoran V. <zv...@ar...>]

Am 30.06.2006 um 21:35 schrieb Vlad Seryakov:

> right
>

Now that we (at least Vlad an myself) have this consensus:

   ns_cache_create
   ns_cache_names
   ns_cache_flush
   ns_cache_eval
   ns_cache_keys
   ns_cache_get
   ns_cache_set
   ns_cache_append
   ns_cache_lappend
   ns_cache_incr
   ns_cache_exists
   ns_cache_lock
   ns_cache_stats

and that ns_cache_create should be able to
create size and time-constrained caches, are
there any other things we need to have there?

For my *personal* taste, the API is way too large
but what I do not use, I do not care for.
I have nothing against having all this in core
and I have nothing against maintaining this
code in future, if the need arises.

Now, please comment...

Stephen, I think that limits as done in AS 4.5 will
not be sufficient for us. As we really do not have,
or better say, do not use the server as pure webserver.
Hence, we need the ability to set time contraints on
cache per-se and not as a part of some larget limits
infrastructure.

Cheers,
Zoran

Re: [naviserver-devel] Cache comands (Was: [naviserver-commits] naviserver ChangeLog, 1.405, 1.406)

[Stephen D. <sd...@gm...>]

On 7/1/06, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Stephen, I think that limits as done in AS 4.5 will
> not be sufficient for us. As we really do not have,
> or better say, do not use the server as pure webserver.
> Hence, we need the ability to set time contraints on
> cache per-se and not as a part of some larget limits
> infrastructure.
>


I have no problem with this.  Just commited to CVS.

The precedence will be: -timeout switch to command, -timeout switch to
ns_cache_create, limits.

Re: [naviserver-devel] Cache comands (Was: [naviserver-commits] naviserver ChangeLog, 1.405, 1.406)

[Zoran V. <zv...@ar...>]

Am 01.07.2006 um 18:17 schrieb Gustaf Neumann:

> Zoran Vasiljevic schrieb:
>> For my *personal* taste, the API is way too large
>> but what I do not use, I do not care for.
>> I have nothing against having all this in core
>> and I have nothing against maintaining this
>> code in future, if the need arises.
>>
>>
> The ns_cache interface resembles much similarity to the nsv interface.
> Essentially, it looks to me
> as an outsider that the main difference to nsv are the options for  
> pool
> size and timeout. Has anyone
> considered to converge nsv and ns_cache by e.g. providing storage  
> pools
> with size and timeout
> to nsv (binding nsv varnames to storage pools)?  Also, the eval
> subcommand makes sense for
> nsv.

Absolutely! This is what I told Vlad in one of the previous emails.
The only *real* difference is the time/size pruning of ns_cache what
nsv's do not have.
I havent examined what would be needed for this thing. Also I wanted to
port thread::tsv interface from the Tcl threading extension to NS.
In that effort I could examine if this would be feasible or not.

What do other people think?

Cheers
Zoran

Re: [naviserver-devel] Cache comands (Was: [naviserver-commits] naviserver ChangeLog, 1.405, 1.406)

[Stephen D. <sd...@gm...>]

On 7/1/06, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 01.07.2006 um 18:17 schrieb Gustaf Neumann:
>
> > Zoran Vasiljevic schrieb:
> >> For my *personal* taste, the API is way too large
> >> but what I do not use, I do not care for.
> >> I have nothing against having all this in core
> >> and I have nothing against maintaining this
> >> code in future, if the need arises.
> >>
> >>
> > The ns_cache interface resembles much similarity to the nsv interface.
> > Essentially, it looks to me
> > as an outsider that the main difference to nsv are the options for
> > pool
> > size and timeout. Has anyone
> > considered to converge nsv and ns_cache by e.g. providing storage
> > pools
> > with size and timeout
> > to nsv (binding nsv varnames to storage pools)?  Also, the eval
> > subcommand makes sense for
> > nsv.
>
> Absolutely! This is what I told Vlad in one of the previous emails.
> The only *real* difference is the time/size pruning of ns_cache what
> nsv's do not have.
> I havent examined what would be needed for this thing. Also I wanted to
> port thread::tsv interface from the Tcl threading extension to NS.
> In that effort I could examine if this would be feasible or not.
>
> What do other people think?
>


Well, nsv, cache, Tcl arrays are all very similar -- key/value
associations.  But it's the small differences which really matter.

Caches are not just size/time limited, they're also assumed to cache
something (!) which is expensive to compute, hence the -timeout switch
and the complicated locking to ensure that should two threads try to
compute a cache value at the same time, one waits for the other to do
the hard work.

Stats only really make sense for caches.  It's not an error for a
cache value to be missing -- caches cache *some* of the data,
hopefully the most frequently used.  You can use the stats to figure
out if this is happening or not.  nsv on the other hand are
server-wide variables.

You might say that Tcl arrays are broken because the values don't expire...  :-)

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Zoran V. <zv...@ar...>]

Am 19.06.2006 um 23:30 schrieb Vlad Seryakov:

> Stephen,
>
> I understand you have the "right" vision how to do things but after  
> long
> period of time just removing Tcl API functions (cache set/get) is not
> very polite.
> It breaks a lot of Tcl code and i am not sure why do you think they  
> are
> racey and i need to emulate them in Tcl instead of C.
>
> Very frustrating.
>
>

I might add couple of words to the above...

Normally, the CVS HEAD is not meant to be used for any production work.
Having said that, I must admit that we do exactly the opposite, i.e.
we take the HEAD and splice it into our product, as-is. This is not a
very good idea as this places extreme (stability) burden for new
developments and things to try out. So I guess we should be doing
tags/minor releases or whatever more frequently. This way we can leave
the HEAD volatile and stick to last known workable state.
A "positive" side effect of using HEAD for production is that we get  
much
better "testing"  but this is also not very good, i.e. to test the code
on the customer sites... Therefore the test-suite should be more  
elaborate
and we are adding more and more there, so I believe this is the right  
way
to go.

Over the time I tried to maintain RFE->Discussion->Implementation
path where one would first inform everybody about what one is going to
do, and why (the RFE), then go see if there are any voices against or
if there are some better ideas, especially if the existing API is being
changed (the Discussion) and finally go implement what is agreed upon
(the Implementation).

Now, I understand that this is a kind of buerocracy but it really  
*helps* resolve
such issues. In later time I could observe that we all neglected the  
RFE/Discussion
part (myself included) which then obviously leads to collisions. So I  
would suggest
that we take the RFE's seriously and start to work on some  
implementation when we
all come to some reasonable consensus.  This will save lots of our  
time and efforts.

The *last* thing I would like to do is to discourage people adding  
new things and
ideas to the code by placing excessive organizational burden to it!
OTOH, adding an RFE allows for others to adjust and comment before  
the code
gets comminted and maintained which will be helpful on the mid/long  
term.

So, afer all this prose, lets see how we will proceed in this  
particular case...
I have no problem in changing our code to adopt to new (better) API.  
I might have
problems if I will have to do that every now and then OR if the API  
does less than
we're used to w/o offering acceptable workarounds.

Cheers,
Zoran

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Vlad S. <vl...@cr...>]

I agree overall, RFE would help especially in case of large API/internal 
changes so everybody would be prepared of what to expect. On the other 
hand, as we talked a year ago, whoever introduces a feature and nobody 
object in the reasonable time(i remember we agreed on 1 week) feature 
remains in the code until something new/better comes up but that will 
need discussion why to remove it because somebody may use it already 
once introduced. We all added a lot of things that everyone of us need 
and that was one of the reasons of this fork, we needed features and we 
added them.

As for CVS HEAD using in the production, i am comfortable with it and 
that is the reason i am adding new things, i have it running on 
pre-production first, and once the feature stable and working it moves 
to production, because i needed it in the production in the first place 
so i added it.

Of course it does not excuse bad decisions which happen from time to 
time but we have mailing list or RFE or CVS to keep the architecture and 
structure sane.

Zoran Vasiljevic wrote:
> Am 19.06.2006 um 23:30 schrieb Vlad Seryakov:
> 
>> Stephen,
>>
>> I understand you have the "right" vision how to do things but after  
>> long
>> period of time just removing Tcl API functions (cache set/get) is not
>> very polite.
>> It breaks a lot of Tcl code and i am not sure why do you think they  
>> are
>> racey and i need to emulate them in Tcl instead of C.
>>
>> Very frustrating.
>>
>>
> 
> I might add couple of words to the above...
> 
> Normally, the CVS HEAD is not meant to be used for any production work.
> Having said that, I must admit that we do exactly the opposite, i.e.
> we take the HEAD and splice it into our product, as-is. This is not a
> very good idea as this places extreme (stability) burden for new
> developments and things to try out. So I guess we should be doing
> tags/minor releases or whatever more frequently. This way we can leave
> the HEAD volatile and stick to last known workable state.
> A "positive" side effect of using HEAD for production is that we get  
> much
> better "testing"  but this is also not very good, i.e. to test the code
> on the customer sites... Therefore the test-suite should be more  
> elaborate
> and we are adding more and more there, so I believe this is the right  
> way
> to go.
> 
> Over the time I tried to maintain RFE->Discussion->Implementation
> path where one would first inform everybody about what one is going to
> do, and why (the RFE), then go see if there are any voices against or
> if there are some better ideas, especially if the existing API is being
> changed (the Discussion) and finally go implement what is agreed upon
> (the Implementation).
> 
> Now, I understand that this is a kind of buerocracy but it really  
> *helps* resolve
> such issues. In later time I could observe that we all neglected the  
> RFE/Discussion
> part (myself included) which then obviously leads to collisions. So I  
> would suggest
> that we take the RFE's seriously and start to work on some  
> implementation when we
> all come to some reasonable consensus.  This will save lots of our  
> time and efforts.
> 
> The *last* thing I would like to do is to discourage people adding  
> new things and
> ideas to the code by placing excessive organizational burden to it!
> OTOH, adding an RFE allows for others to adjust and comment before  
> the code
> gets comminted and maintained which will be helpful on the mid/long  
> term.
> 
> So, afer all this prose, lets see how we will proceed in this  
> particular case...
> I have no problem in changing our code to adopt to new (better) API.  
> I might have
> problems if I will have to do that every now and then OR if the API  
> does less than
> we're used to w/o offering acceptable workarounds.
> 
> Cheers,
> Zoran
> 
> 
> 
> 
> 
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] [naviserver-commits] naviserver ChangeLog, 1.405, 1.406

[Zoran V. <zv...@ar...>]

Am 20.06.2006 um 16:21 schrieb Vlad Seryakov:

> On the other
> hand, as we talked a year ago, whoever introduces a feature and nobody
> object in the reasonable time(i remember we agreed on 1 week) feature
> remains in the code until something new/better comes up but that will
> need discussion why to remove it because somebody may use it already
> once introduced. We all added a lot of things that everyone of us need
> and that was one of the reasons of this fork, we needed features  
> and we
> added them.

Allight! Well, you objected immediately... Lets see what Stephen
can add to that.
I yet have to digest the change but will definitely object if
I'm not able to give alternate timeouts for different caches.
Also, I'd keep the cache API as simple as possible.

>
> As for CVS HEAD using in the production, i am comfortable with it and
> that is the reason i am adding new things, i have it running on
> pre-production first, and once the feature stable and working it moves
> to production, because i needed it in the production in the first  
> place
> so i added it.

Good. So there is no so big harm at the moment for you. For ourselves,
we must go and get this stabilized at some point as I'm planning
to get our 2.3 release out and for that I need stable nscache and
nsproxy.

Cheers
Zoran