naviserver-devel — Developer discussion

Re: [naviserver-devel] ns as loadable extension

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

On Wed, May 7, 2008 at 10:00 PM, Jeff Rogers <dv...@di...> wrote:
> Andrew Piskorski wrote:
>> On Wed, May 07, 2008 at 05:05:13PM +0200, Vasiljevic Zoran wrote:
>>
>>> Does anybody have any interest in making us being a
>>> yet-another Tcl loadable extension?
>>
>> Yes.  From his past comments on the AOLserver list, Jeff Hobbs would
>> probably be interested too.
>
> Rather than the entire server being a loadable extension, what about
> breaking out the major c-coded functional pieces into a group of
> loadable extensions?  The modules could include adp (a fast/extensible
> template engine), urlspace (a trie oriented around urls), driver (a
> threaded alternate to the standard tcl event loop, oriented around
> creating events on one thread to be dispatched on others), and of
> course, db for database access.


It wouldn't be too hard to enable nsdbi as a Tcl package. It can
already change config settings at runtime. It just needs to be taught
to use those commands to load it's initial config when first loaded,
and a couple of other bits and pieces.

Re: [naviserver-devel] ns as loadable extension

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

On Wed, May 7, 2008 at 7:59 PM, Vasiljevic Zoran <zv...@ar...> wrote:
>
> On 07.05.2008, at 19:15, Vlad Seryakov wrote:
>
>> Once you started the server, it is not Tcl package anymore, need
>> nscp to
>> access it.
>
>
> Depends. If you think in the box, yes. If you step out
> of the box then yes and no.
>
> What I actually think is to marry the rw-config module
> with the code and make the server configuration from
> Tcl. Say, each new virtual server gets its own Tcl
> command that can be used to modify the config on the
> fly etc.pp. The whole idea is still in a very very
> rudimentary state. What I would like to achieve is
> really to get more people evaluate the server by
> simply snap-in the package and fire-up one or more
> virtual servers. All under exteral (Tcl) control.
>
> This would mean some considerable re-plumbing in
> ns_main.c but it ls doable. Allright, perhaps
> some more plumbing...
>


Some kind of ns_daemon command as a module, incorporating all the
startup guts such as the forking into the background, session id
stuff, changing user/group, chroot, windows service/unix watchdog.
That would be a genuinely useful standalone Tcl module, and might
actually clean up some of the startup code.

So 'nsd' would be a Tcl script which parses the command line, calls
ns_daemon -user .. -group .. -chroot .. (or whatever) and then jumps
into the main main libnsd binary.

The 'daemon' stuff seems to be a logical chunk of functionality.

Re: [naviserver-devel] Mercurial: naviserver.sourceforge.net/hg/

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

On Fri, May 23, 2008 at 9:50 PM, Vlad Seryakov <vl...@cr...> wrote:
> Another question: why to keep every module in separate repo?
> will it be easier to have them under one root?


No, they need to be separate repos.

The reason is that unlike cvs hg is changeset based. There is one
commit message that goes with the changes to a collection of files.
They go together, like a transaction in a db.

When you do a 'hg log' you get the commit message, user, date etc. for
each changeset. If we put all the modules into one repo then it would
be like have just one ChangeLog for everything, with all message mixed
together. Also, things like tags are repo wide, and you don't really
want to tag nsdbi with naviserver-4.99.2, and vice-versa.

There is an extension call 'forrest' which is something like repos
within repos. I don't know if it's needed though.

To keep updated, you could just stick something like the following in cron:

for repo in ~/in/ns/*-hg; do
  hg -R $repo pull
done

We could publish a shell script with a list of all modules, to
bootstrap for those who want a copy of everything.


Also, slightly related, I think we want to follow a repo-as-branch
model. So no branches within repos. It's simpler.

Re: [naviserver-devel] gzip compression fixes

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

http://naviserver.sourceforge.net/hg/naviserver/rev/3f16ccfc8985

What are the bugs that are fixed here? The message doesn't say.

Also, it breaks the tests:

$ make test
...
==== ns_adp_conpress-1.2 Accept-Encoding gzip FAILED
==== Contents of test case:

    set response [nstest_http -encoding binary -setheaders
{accept-encoding gzip}  -getheaders {content-encoding} -getbody 1 GET
/ns_adp_compress.adp]
    binary scan [lindex $response 2] "H*" values
    list [lindex $response 0] [lindex $response 1] [regexp -all
-inline {..} $values]

---- Result was:
200 gzip {1f 8b 08 00 00 00 00 00 00 03 2b c9 c8 2c 56 00 a2 44 85 92
d4 e2 12 00 ea e7 1e 0d 0e 00 00 00}
---- Result should have been (exact matching):
200 gzip {1f 8b 08 00 00 00 00 00 00 03 2b c9 c8 2c 56 00 a2 44 85 92
d4 e2 12 00 26 33 05 16 0d 1e e7 ea 00 00 00 0e}
==== ns_adp_conpress-1.2 FAILED



It's tough to know which is right, the code or the test, with no hints
in the commit message... :-)


  http://naviserver.sourceforge.net/hg/naviserver/log/3fe51589271f/tests/ns_adp_compress.test

Re: [naviserver-devel] Mercurial: naviserver.sourceforge.net/hg/

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

Another question: why to keep every module in separate repo?
will it be easier to have them under one root?

Stephen Deasey wrote:
> On Fri, May 23, 2008 at 8:45 PM, Vlad Seryakov <vl...@cr...> wrote:
>> I am personally ready to switch right away, i use hg for xine-lib for a
>> long time already, in readonly mode but it did not require much learning
>> to use it.
>>
>> More questions, is hg repo hosted by SF? Is it Sf service or you just
>> run additional hg server there?
> 
> 
> I basically followed this recipe:
> 
> http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourceforge
> 
> Although I used mercurial-1.0  (installed into
> /home/groups/n/na/naviserver/local/mercurial-1.0)
> 
> All the repos live in /home/groups/n/na/naviserver/hg
> 
> Mercurial comes with cgi-scripts to publish the repos, that's what you
> see when you go to:
> 
>   http://naviserver.sourceforge.net/hg/
> 
> (See: /home/groups/n/na/naviserver/cgi-bin)
> 
> (And btw. you can get the same view on your own machine by typing 'hg
> serve', built-in web server).
> 
> 
> So, the repos in $SF/hg  are basically identical to what you end up
> with on your own machine when you clone. The only difference is that I
> modified the per-repo hgrc file to add the hooks for commit messages
> and a couple of other small things.
> 
> I guess I should make clear, the naviserver repo, and each of the
> module repos would in fact be individual repos.
> 
> 
> So to convert the other modules from cvs, you'd run 'hg convert'
> (which you have to enable first, it's an extension shipped with
> mercurial). And then you'd clean it up a little, make sure the commit
> messages follow the mercurial style etc. And then you'd clone it up
> there:
> 
>   hg clone ./nsexample ssh://sf/ns/hg/nsexample
> 
> And then you would ssh into sf and copy the hgrc from an existing repo
> into the new one:
> 
>   ssh sf
>   cd ~/ns/hg
>   cp naviserver/.hg/hgrc nsexample/.hg/hgrc
>   vi nsexample
> 
> It should show up in the web interface automatically.  You only need
> to edit the top of the file to change the display name, basically just
> this:
> 
>   [web]
>   description = Programmable Web Server
> 
>   [cia]
>   module = naviserver
> 
> You could also edit 'contact' if you like. It's just for display on
> the web interface.
> 
> 
> That should be it.  We can go into more details about how to convert
> modules from cvs later, but shout out if you're keen to get started.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

Re: [naviserver-devel] Mercurial: naviserver.sourceforge.net/hg/

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

On Fri, May 23, 2008 at 8:45 PM, Vlad Seryakov <vl...@cr...> wrote:
> I am personally ready to switch right away, i use hg for xine-lib for a
> long time already, in readonly mode but it did not require much learning
> to use it.
>
> More questions, is hg repo hosted by SF? Is it Sf service or you just
> run additional hg server there?


I basically followed this recipe:

http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourceforge

Although I used mercurial-1.0  (installed into
/home/groups/n/na/naviserver/local/mercurial-1.0)

All the repos live in /home/groups/n/na/naviserver/hg

Mercurial comes with cgi-scripts to publish the repos, that's what you
see when you go to:

  http://naviserver.sourceforge.net/hg/

(See: /home/groups/n/na/naviserver/cgi-bin)

(And btw. you can get the same view on your own machine by typing 'hg
serve', built-in web server).


So, the repos in $SF/hg  are basically identical to what you end up
with on your own machine when you clone. The only difference is that I
modified the per-repo hgrc file to add the hooks for commit messages
and a couple of other small things.

I guess I should make clear, the naviserver repo, and each of the
module repos would in fact be individual repos.


So to convert the other modules from cvs, you'd run 'hg convert'
(which you have to enable first, it's an extension shipped with
mercurial). And then you'd clean it up a little, make sure the commit
messages follow the mercurial style etc. And then you'd clone it up
there:

  hg clone ./nsexample ssh://sf/ns/hg/nsexample

And then you would ssh into sf and copy the hgrc from an existing repo
into the new one:

  ssh sf
  cd ~/ns/hg
  cp naviserver/.hg/hgrc nsexample/.hg/hgrc
  vi nsexample

It should show up in the web interface automatically.  You only need
to edit the top of the file to change the display name, basically just
this:

  [web]
  description = Programmable Web Server

  [cia]
  module = naviserver

You could also edit 'contact' if you like. It's just for display on
the web interface.


That should be it.  We can go into more details about how to convert
modules from cvs later, but shout out if you're keen to get started.

Re: [naviserver-devel] moonshadow

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

On Thu, May 15, 2008 at 6:52 PM, Vasiljevic Zoran <zv...@ar...> wrote:
>
> On 11.05.2008, at 15:42, Stephen Deasey wrote:
>
>>
>> Undocumented:
>>
>>    generic/tclResolve.c: Tcl_AddInterpResolvers()
>>
>>
>>
>> You could probably even fake-up a solution using a single interp with
>> your own name resolvers. Before you start executing the code for a
>> single client, set a 'context' global which your resolver routines
>> will use to keep state variables separate for each client.
>
> Hmhmhm... I do not really follow....
>
> I cannot do that with a single interp. As it is bound to a thread.
> So - single interp - single thread. How do I scale?


You mentioned that you didn't want to rewrite a complicated state
machine that uses a lot of uplevels, in an event style. I thought
maybe you could keep the variables separate using these namespace
lookup procs. Then you could use a single interp to manage multiple
state machines, instead of using the stacks of 1000 threads.

You could give each client an id on first connect and put them in
buckets, with buckets >=1 and <= 1000. You need a pool of threads, one
for each bucket.  When a message arrives from a client, you sent it to
the same thread/bucket each time. The interps of those threads are
persistent.

Within the bucket interps you use the namespace lookup trick to
subdivide the variable space between the clients which are assigned to
that interp. The interp runs a client message to completion, then
picks up the next. Your concurrency level is however many buckets you
decide to subdivide the 1000 connections into.

Re: [naviserver-devel] Mercurial: naviserver.sourceforge.net/hg/

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

I am personally ready to switch right away, i use hg for xine-lib for a 
long time already, in readonly mode but it did not require much learning 
to use it.

More questions, is hg repo hosted by SF? Is it Sf service or you just 
run additional hg server there?

Stephen Deasey wrote:
> On Fri, May 23, 2008 at 7:39 PM, Vlad Seryakov <vl...@cr...> wrote:
>> Does that mean i have to use either one, CVS or HG, not both at the same
>> time?
>> What i am asking, we still have 2 repos, will it work if commits are
>> coming to both of them?
> 
> 
> No, we should use one or the other.
> 
> Or, we should treat what's in the hg repos now as a demo/test and plan
> to redo them later.
> 
> 
> 
> You could commit your recent change to the hg repo and then they will
> be in synch again, and we can decide what to do. You can be the guinea
> pig :-)
> 
> btw. I deleted the ChangeLog in the hg repo. The commit log messages
> should be enough.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

Re: [naviserver-devel] ns_share

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

On Sun, May 18, 2008 at 6:09 PM, Vasiljevic Zoran <zv...@ar...> wrote:
> Hi again!
>
> This is yet-antother scrap candidate. I wonder if
> anybody is still using this ancient interface?
> I would like to get it out as to keep the code
> smaller and simpler to maintain.


It would be great if it could be made to compile as a standalone
module, as was done with some of the old db modules that we removed,
such as nsdbext. I think ns_share is pretty separate, maybe just need
something to hang the per-server stuff off which is currently in the
NsServer struct.

Also, there is some ns_var stuff in nsd/tclvar.c that probably belongs
with ns_share.  I think the progression went ns_share -> ns_var ->
nsv_*, with ns_var being born already superseded by nsv_* when aol
released it.

Re: [naviserver-devel] Mercurial: naviserver.sourceforge.net/hg/

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

On Fri, May 23, 2008 at 7:39 PM, Vlad Seryakov <vl...@cr...> wrote:
> Does that mean i have to use either one, CVS or HG, not both at the same
> time?
> What i am asking, we still have 2 repos, will it work if commits are
> coming to both of them?


No, we should use one or the other.

Or, we should treat what's in the hg repos now as a demo/test and plan
to redo them later.



You could commit your recent change to the hg repo and then they will
be in synch again, and we can decide what to do. You can be the guinea
pig :-)

btw. I deleted the ChangeLog in the hg repo. The commit log messages
should be enough.

Re: [naviserver-devel] drop CVS

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

On Wed, May 7, 2008 at 6:56 PM, Vlad Seryakov <vl...@cr...> wrote:
> One benefit i can see is not immediate and obvious but having more
> flexible source control system may attract or make it easy to handle
> access to more developers, easy to revert unneeded changes, as Stephan
> pointed, better patch control and changsets.
>
> Yes, it will require some learning but not that much, still this is just
> source control system, using it in the-CVS-mode, as commit/update/diff,
> will be possible with any tool.
>


Yeah, for this particular project then a new version control system is
not going to bring new developers stampeding through the door. But
there is some potentially nice usability benefits for newbies.

A couple of times recently on the aolserver list there should have
been some patches flowing but instead either whole files or tarballs
have been posted, making it extremely difficult to figure out whats
been changed, and making it unlikely that the changes will be
incorporated into cvs.  The mechanics of doing it right aren't hard
per-se, but it can be non obvious and sometimes it's a pain.
Obviously there are other problems with aolserver development, but if
there was a culture of passing patches back and forth it would make up
for a lot.

I think in general we've just scratched the surface of how to work
with dvcs'.  A lot of focus has been put on some of the new technical
abilities, just as svn was better because of atomic commits, renames
etc. But the new systems have a lot more headroom for new ways to
work.  It's interesting to me, that after ~ 3 years use of git for
kernel development they're even now having discussions about whether
or not you should rebase if you're a maintainer (pull and rebase other
peoples patches). You shouldn't, apparently, and the way it was
explained makes sense (saw this on kerneltrap.org I think, if you're
interested).

It will be cool to see how open source development is done in a couple
of years when we figure this all out...

Re: [naviserver-devel] drop CVS

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

On Wed, May 7, 2008 at 11:24 AM, Gustaf Neumann <ne...@wu...> wrote:
>
> Let me point out another nice feature of git:
> git provides server-support to behave to clients like a
> cvs and/or svn server. This means, one can access the git
> repository from cvs or svn (or git) clients. Not sure
> if this is an issue, but a user who does not want to
> learn new commands can contiune to use the CVS interface.


I'm not sure this is actually useful.  You can't really commit from
cvs or svn, and a straight checkout is actually easier in hg and git
than cvs, which requires you to specify a user even if it's just anon,
and they often show this in two stages.

For those who don't want to install any extra tools I've enabled the
tarball feature. You can grab a tarball of any revision of any project
straight from the web interface.


> I personally like git for its speed and simplicity to setup and
> usage. Git has certain ideosyncharies (e.g. does not like
> empty directories), and the downside is that if the full
> feature set of a more distributed scm is used, things become
> quite complex, at least for a casual user.


Git is very nice. But it is considerably harder to use than hg.  Even
for someone like Zoran, who is quite capable, but is too busy to faff
around with something like this, I think that would be a barrier.

The main thing for me re hg and git is that you can't go wrong with
either of them, where as cvs and svn have too much baggage these days
and most of the other systems have serious problems some where.
Bazaar is probably a solid 3rd -- a Dr. Pepper to the Coke and Pepsi
of git hg...  :-)

Re: [naviserver-devel] drop CVS

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

On Wed, May 7, 2008 at 11:03 AM, Ibrahim Tannir <it...@ar...> wrote:
> FWIW, to let my paranoia out:
>
> I don't like SVN because it obscures and packs the whole
> repository into one big file, which IMHO overshadows all its
> benifits.
>
> I've been able in tha past to resolve the consequences of quite a
> few CVS bugs, due to the open structure of its repository.
>

That's a good point.

Mercurial and Git etc. are inherently better than cvs/svn because each
time someone clones they get the full repo. A kind of built-in backup.

That doesn't protect against cosmic rays, Murpheys Law. Perhaps a nice
way to handle this is to use the ultimate text format as backup -
patches.  Mercurial has the nice feature that you can export commits
as patches with a set of special headers which preserve the
mercurial-specific info, such as the hashes, and the stuff that
patches don't carry, such as the username, date etc.

You could set up a trigger to dump a copy of each commit as a patch in
some directory. I haven't tried, but I guess it wouldn't be too hard.

You can simulate it by importing the whole repo into a patch queue:

  hg clone ~/in/naviserver ~/ns-test
  cd test
  hg qinit
  hg qimport -r :

The ':' is python-like slice notation for a range of commits, which in
this case says 'everything'. You could also say -r 0:tip.

The patches are kept in numbered order in:

  ~/ns-test/.hg/patches

Another of the nice properties of mercurial is the content hashing,
which like git uses sha1 to hash the content of each changeset,
including the metadata. Mercurial also mixes in the hash of the
parent(s) changesets. So, when you reapply all the patches to
reconsitute the repo, and corruption will be noticed because the
hashes won't match.

This would be a nice little project for someone...

Re: [naviserver-devel] Mercurial: naviserver.sourceforge.net/hg/

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

Does that mean i have to use either one, CVS or HG, not both at the same 
time?
What i am asking, we still have 2 repos, will it work if commits are 
coming to both of them?

Stephen Deasey wrote:
> I updated the naviserver mercurial repo with the latest changes from
> cvs put it on sourceforge:
> 
>   http://naviserver.sourceforge.net/hg/
> 
> 
> To check it out:
> 
>   hg clone http://naviserver.sourceforge.net/hg/naviserver  ~/in/naviserver-hg
> 
> Or, if you've already cloned from the freehg.org repo, you can simply
> update with the differences:
> 
>   hg -R ~/in/navserver-hg pull -u
> 
> The -u at the end means 'and update the working directory'. pull and
> update are 2 separate things.
> The -R saves you from CD'ing into the repo directory.
> 
> If you are updating instead of cloning, you might want to change the
> default pull location in the repo config file:
> 
>   ~/in/naviserver-hg/.hg/hgrc
> 
>   [paths]
>   default = http://naviserver.sourceforge.net/hg/naviserver
> 
> Now you don't have to specify where to pull from each time. cd into
> the repo directory and 'hg pull -u'. Same for other commands which
> work with two repos: incoming, outgoing etc.
> 
> 
> I guess that's how most people would grab a copy of the latest source.
> For people who expect to commit to the public repo themselves you
> might want to clone via ssh. A couple of prerequisites:
> 
> Add something like the following to your ~/.ssh/config file:
> 
>   Host sf shell.sf.net
>     Hostname  shell.sf.net
>     User          yoursfusername
> 
> log into sf and do the following:
> 
>   ssh sf
>   ln -s /home/groups/n/na/naviserver ~/ns
>   echo "source /home/groups/n/na/naviserver/bashc" >> ~/.bashrc
> 
> bashrc just sets the umask correctly and adds the 'hg' command to the PATH.
> 
> Now you can clone via ssh:
> 
>   hg clone ssh://sf/ns/hg/naviserver ~/in/naviserver-hg
> 
> That's also where you push to make your commits public.
> 
>   hg clone ~/in/naviserver-hg ~/ns-work
>   cd ~/work
>   ... hack hack hack ...
>   hg commit
>   hg push ssh://sf/ns/hg/naviserver
> 
> 
> For people who don't have direct commit access, and with mercurial
> that's really no disadvantage, perhaps a good way to work is to use
> the 'patchbomb' extension.  Add the following to your ~/.hgrc file:
> 
>   [extensions]
>   patchbomb=
> 
>   [email]
>   from = Your Name <you@wherever>
> 
>   [smtp]
>   host = smtp.gmail.com
>   port = 587
>   tls = 1
>   username = you@wherever
>   password = ****
> 
> (or whatever)
> 
> btw. you'll also want to make sure that the following is present --
> it's what your name appears as in the commit message:
> 
>   [ui]
>   username = Your Name <you@wherever>
> 
> 
> Now, to publish your last commit (the tip, aka HEAD) you could do:
> 
>   hg email -r tip --to nav...@li...
> 
>   ('hg help email' for more)
> 
> The patch is created as an attachment such that it can exactly
> reproduce the commit when imported to another repo, including the
> committer name, date etc., so full credit is always given.  At this
> point some one with commit access would import the patch, check it,
> and if OK push it:
> 
>   hg import ~/saved-email
>   hg push
> 
> 
> Commit Messages:
> 
> Format them like an email. A single like subject of about ~70 chars,
> followed by a blank like, followed by the body, word wrapped to ~80
> chars.  Keyword stuff the subject so that folks can get the gist of it
> by skimming. Prefix with a module name such as nsperm: if you think it
> makes sense. Say 'Add ...' instead of 'Added ...'.
> 
> 
> 
> The commit messages should be working, and so is cia.vc. Here's an example:
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=hg.1883a10a6e0c.1210791169.-2015825136%40sc8-pr-shella-b.sourceforge.net
> 
> 
> Does this all look OK?
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

[naviserver-devel] Mercurial: naviserver.sourceforge.net/hg/

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

I updated the naviserver mercurial repo with the latest changes from
cvs put it on sourceforge:

  http://naviserver.sourceforge.net/hg/


To check it out:

  hg clone http://naviserver.sourceforge.net/hg/naviserver  ~/in/naviserver-hg

Or, if you've already cloned from the freehg.org repo, you can simply
update with the differences:

  hg -R ~/in/navserver-hg pull -u

The -u at the end means 'and update the working directory'. pull and
update are 2 separate things.
The -R saves you from CD'ing into the repo directory.

If you are updating instead of cloning, you might want to change the
default pull location in the repo config file:

  ~/in/naviserver-hg/.hg/hgrc

  [paths]
  default = http://naviserver.sourceforge.net/hg/naviserver

Now you don't have to specify where to pull from each time. cd into
the repo directory and 'hg pull -u'. Same for other commands which
work with two repos: incoming, outgoing etc.


I guess that's how most people would grab a copy of the latest source.
For people who expect to commit to the public repo themselves you
might want to clone via ssh. A couple of prerequisites:

Add something like the following to your ~/.ssh/config file:

  Host sf shell.sf.net
    Hostname  shell.sf.net
    User          yoursfusername

log into sf and do the following:

  ssh sf
  ln -s /home/groups/n/na/naviserver ~/ns
  echo "source /home/groups/n/na/naviserver/bashc" >> ~/.bashrc

bashrc just sets the umask correctly and adds the 'hg' command to the PATH.

Now you can clone via ssh:

  hg clone ssh://sf/ns/hg/naviserver ~/in/naviserver-hg

That's also where you push to make your commits public.

  hg clone ~/in/naviserver-hg ~/ns-work
  cd ~/work
  ... hack hack hack ...
  hg commit
  hg push ssh://sf/ns/hg/naviserver


For people who don't have direct commit access, and with mercurial
that's really no disadvantage, perhaps a good way to work is to use
the 'patchbomb' extension.  Add the following to your ~/.hgrc file:

  [extensions]
  patchbomb=

  [email]
  from = Your Name <you@wherever>

  [smtp]
  host = smtp.gmail.com
  port = 587
  tls = 1
  username = you@wherever
  password = ****

(or whatever)

btw. you'll also want to make sure that the following is present --
it's what your name appears as in the commit message:

  [ui]
  username = Your Name <you@wherever>


Now, to publish your last commit (the tip, aka HEAD) you could do:

  hg email -r tip --to nav...@li...

  ('hg help email' for more)

The patch is created as an attachment such that it can exactly
reproduce the commit when imported to another repo, including the
committer name, date etc., so full credit is always given.  At this
point some one with commit access would import the patch, check it,
and if OK push it:

  hg import ~/saved-email
  hg push


Commit Messages:

Format them like an email. A single like subject of about ~70 chars,
followed by a blank like, followed by the body, word wrapped to ~80
chars.  Keyword stuff the subject so that folks can get the gist of it
by skimming. Prefix with a module name such as nsperm: if you think it
makes sense. Say 'Add ...' instead of 'Added ...'.



The commit messages should be working, and so is cia.vc. Here's an example:

http://sourceforge.net/mailarchive/message.php?msg_id=hg.1883a10a6e0c.1210791169.-2015825136%40sc8-pr-shella-b.sourceforge.net


Does this all look OK?

Re: [naviserver-devel] ns_share

[Bernd E. <eid...@we...>]

> On 18.05.2008, at 19:13, Vlad Seryakov wrote:
> > i've never used it
>
> Neither have I.

Nor do we.

Bernd.

Re: [naviserver-devel] ns_share

[Vasiljevic Z. <zv...@ar...>]

On 18.05.2008, at 19:13, Vlad Seryakov wrote:

> i've never used it

Neither have I. I guess if nobody objects in a week
I will scrap that code, in an everlasting effort to
keep things simple.

Re: [naviserver-devel] ns_share

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

i've never used it

Vasiljevic Zoran wrote:
> Hi again!
> 
> This is yet-antother scrap candidate. I wonder if
> anybody is still using this ancient interface?
> I would like to get it out as to keep the code
> smaller and simpler to maintain.
> 
> Cheers
> Zoran
> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

-- 
Vlad Seryakov
vl...@cr...
http://www.crystalballinc.com/vlad/

[naviserver-devel] ns_share

[Vasiljevic Z. <zv...@ar...>]

Hi again!

This is yet-antother scrap candidate. I wonder if
anybody is still using this ancient interface?
I would like to get it out as to keep the code
smaller and simpler to maintain.

Cheers
Zoran

Re: [naviserver-devel] conf cleanup

[Vasiljevic Z. <zv...@ar...>]

On 18.05.2008, at 15:57, Vasiljevic Zoran wrote:

>
> Any reasons why we should not scrap those away?

Ah, won't work. [ns_library] uses those for loading modules.
Too bad! I keep on looking for things we can ditch.

Cheers
Zoran

[naviserver-devel] conf cleanup

[Vasiljevic Z. <zv...@ar...>]

Hi!

Another candidate:

   nsconf.tcl.sharedlibrary

This was used in pre-naviserver code to locate and load
Tcl files. In addition to that, there is also per server

   servPtr->tcl.library

Both are not used by the code any more. There is also
C-API Ns_TclLibrary that returns the config value and
[ns_info] list element that reflects this in Tcl API.

Suggestion: remove nsconf.tcl.sharedlibrary and
servPtr->tcl.library config, Ns_TclLibrary call and
leave an empty string at the corresponding place in
[ns_info] (alternatively scrapping the element
altogether).

Any reasons why we should not scrap those away?

Cheers
Zoran

Re: [naviserver-devel] [naviserver-commits] naviserver/nsd driver.c, 1.97, 1.98

[Vasiljevic Z. <zv...@ar...>]

On 12.05.2008, at 11:14, Vasiljevic Zoran wrote:

>
> So, YES. Rip it out! Who's the volunteer? If no objections I
> will have the pleasure...

No volunteers, hence I did that. The sndbuf/rcvbuf elements of
the driver struct plus accompanying config code is ripped out.

Cheers
Zoran

Re: [naviserver-devel] moonshadow

[Vasiljevic Z. <zv...@ar...>]

On 11.05.2008, at 15:42, Stephen Deasey wrote:

>
> Undocumented:
>
>    generic/tclResolve.c: Tcl_AddInterpResolvers()
>
>
>
> You could probably even fake-up a solution using a single interp with
> your own name resolvers. Before you start executing the code for a
> single client, set a 'context' global which your resolver routines
> will use to keep state variables separate for each client.

Hmhmhm... I do not really follow....

I cannot do that with a single interp. As it is bound to a thread.
So - single interp - single thread. How do I scale?

I normally have, say, couple of hundred of connections to the
server, all with a separate state. The simple and most straight
forward is to keep that state (a connection socket to the client,
client's private data) in a per-client sandbox.
At the moment a Tcl interp and separate thread give me the needed
"sandbox". Yet, currently that would blow the servers memory given
my app metrics. To make the sandbox small, I just create an empty
interp and route (message-passing) API calls to _something_ else.
This keeps the sandbox reasonably small. I was hoping to find a
generic solution to this, yet I do not know how :-(
My only chance is to rewrite (or write new) app logic that encapsulates
the required functionality in a high-level API and then route API
calls to a battery of equally-created-threads, each fully loaded with
the complete command set and state.

The [ns_job] is quite a good example to what I need. But it is
clumsy to use. Ideally, one would just call API calls directly in Tcl
and that would automagically be ran in some distant/other interp.
Well, that means, of course that API needs to be completely wrapped
in the sense that I can only communicate scalar values with it
(no refrerences, file handles, other handles etc pp) as the whole API
state is uknown in the sandbox AND I have no per-interp affinity in
my "computing-battery-of-threads" as this would limit my scalability.

Now, I hope I managed to convey the picture. How do you see the above
Tcl API could help me? What I understand is that this is ment to be
helpful for extension writers to impmenent new language extensions
(oo systems in particular) with custom var and command resolvers but
all this is private to the calling thread. Or isn't it?

Cheers
Zoran

Re: [naviserver-devel] [naviserver-commits] naviserver/nsd tcljob.c, 1.30, 1.31

[Vasiljevic Z. <zv...@ar...>]

On 11.05.2008, at 20:41, Stephen Deasey wrote:

>
> Should call Ns_Fatal() here, not Ns_Log(Fatal, ...)
>
> (Ns_Log(Fatal, ) is kind of a hidden implementation detail)

Allright.

Re: [naviserver-devel] [naviserver-commits] naviserver/nsd tclobj.c, 1.7, 1.8

[Vasiljevic Z. <zv...@ar...>]

On 12.05.2008, at 14:41, Stephen Deasey wrote:

> I was just passively-aggressively suggesting you don't run 'make test'
> enough...  :-)

I know. Huh. There must be a reason to that. And the reason is that I  
have
a "slightly" diffent build for our product which is sometimes (link- 
wise)
colliding with off-the-shelf build. In order to "make test" I first need
to remove/save /usr/local/ns, then "make install" then "make test"  
then I
need to re-activate my private state. This isn't that complex but when
you are under time-constraints (i am always under time-constraints) you
default to saving time wherever you can. The "make test" is a first
candidate most of the time...

>
>
> Also, there's no tests/ns_job.test to cover all those bugs you fixed.

There are no bugs got fixed. Rather I added new feature and while
adding it, I made some errors because of the non-transparent locking
strategy. Which I then fixed again. So the only real test that should
go there is to check the (new) script cancellation.
I will put this on the my list.

FWIW: please DO continue to bug myself and others to keep good
practices. This increases the quality of the code and I am ALL
for it.

Cheers
Zoran