naviserver-devel — Developer discussion

Re: [naviserver-devel] Release/Docs

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

Am 04.07.2005 um 10:14 schrieb Bernd Eidenschink:

>> than one C-API call. To get an idea, install Tcl and make:
>>
>>    man Tcl_FSStat
>>
>> and you will see that the *entire* Tcl-VFS API is documented in
>> one single man-page.
>>
> ok, see. would be handy.

Watch! Although handy, it is pretty inflexible.
As an exercise, imagine you'd like to use Tcl_AllocStatBuf call.
Now, you naively go and "man Tcl_AllocStatBuf". You'd like to
get call signature and parameter description, but you also want
to look at what the call is really doing. Given the current state,
this is all but user-friendly and effective.

In order to understand what I mean, please do try "man Tcl_AllocStatBuf"
and judge by yourself...
Personally, I find it very annoying and ineffective.

>
>
>> Wiki seems very nice for collaborative work but I do not
>> know if there is a wiki->doctools converter (doctools->wiki there  
>> is).
>> If we start hacking wiki, how would you convert this into some
>> other format?
>>
> Depends on what we need for doctools, or generally for documentation.
> Example:
> All Headings like NAME,SYNOPSIS,DESCRIPTION,EXAMPLES,SEE  
> ALSO,KEYWORDS are
> representated the same in the wiki, e.g. a third-level-heading:
> === SEE ALSO ===
> Other "markup" like bold or underline is also easy parseable  
> ('''bold''').
> "Examples" start with one or more whitespace on a line.
>
> So I think it should be very easy to hack a convert, as the  
> structure is
> always the same. Like this stupid hack:
> http://naviserver.sourceforge.net/wiki/index.php/News2wiki.tcl
>
> But, as the devil is in the details, maybe you send me a doctool- 
> document in
> the form that you can imagine as a template for NaviServer, and I  
> take a look
> at how complex it is to write a small converter script.

OK. I will prepare a doctool for a one ns_xyz and Ns_XYZ() (both Tcl  
and C api).
You must install tcllib and there you will have a dtp utility which will
translate this in wiki or html or nroff for you.
If it turns out to be simple to write a wiki->doctools converter then  
I'm all
for it. Then we'd use wiki to fill-in the content, use the translator to
generate doctools pages, then cvs-import those, then generate html/nroff
offline docs during installation. Ideally, the wiki->doctools should be
somehow automated.

Hm.... and what if we'd have a wiki->nroff and wiki->html off-line
converters? Than we'd have the sources of docs in native wiki format
and check-in those in CVS. During the "make install" we'd hit the
apropriate converter and generate html/nroff on the fly? Or we can
pre-format nroff/html and check-in those... ??

This way or another, it seems that if we'd have a wiki->html and
wiki->nroff converters at hand, we could trash doctools... But I
do not know if any of those already exists. OK, the wiki->html
should already be there, otherwise wiki would not work ;-)
But, what about wiki->nroff ?

>
>
>> The AS project started this and I do not see any moves
>> there. The wiki-entered stuff is still there and nobody cares to
>> get it into the CVS or get it translated to other off-line reading
>> (man, html, pdf, etc) ?
>>
>
> Thats true. I think the effort stopped at the very beginning or  
> halfway. But
> if only we had it in the Wiki! The problem is that writing  
> documentation
> sucks, not writing the converter :-)))

But yet, having a good framework in place would actually lower the
barrier of having to start to write actually.
>
> Ok. But we should have a complete list for C and TCL to know whats  
> missing or
> when we are finished.

If we manage to get Wiki-based thing, than all is already in-place,  
right?


> I started with TCL, but the list is not perfect:
> http://naviserver.sourceforge.net/wiki/index.php/Examples:Commands
>

The problems with the list is that you need to update yet-another-thing.

>
>> I think that tagging the CVS now with 4.99.0 is perfectly OK as it  
>> would
>> identify a body in CVS which is fixed and against which we can file
>> bugs.
>>
>
> Ok, so we tag it after the macro insertion (or whatever solution)  
> for the
> range headers?
>


I would suggest so.

Zoran

Re: [naviserver-devel] Release/Docs

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

> than one C-API call. To get an idea, install Tcl and make:
>
>    man Tcl_FSStat
>
> and you will see that the *entire* Tcl-VFS API is documented in
> one single man-page. 
ok, see. would be handy.

> Wiki seems very nice for collaborative work but I do not
> know if there is a wiki->doctools converter (doctools->wiki there is).
> If we start hacking wiki, how would you convert this into some
> other format? 
Depends on what we need for doctools, or generally for documentation.
Example:
All Headings like NAME,SYNOPSIS,DESCRIPTION,EXAMPLES,SEE ALSO,KEYWORDS are 
representated the same in the wiki, e.g. a third-level-heading:
=== SEE ALSO ===
Other "markup" like bold or underline is also easy parseable ('''bold''').
"Examples" start with one or more whitespace on a line.

So I think it should be very easy to hack a convert, as the structure is 
always the same. Like this stupid hack:
http://naviserver.sourceforge.net/wiki/index.php/News2wiki.tcl

But, as the devil is in the details, maybe you send me a doctool-document in 
the form that you can imagine as a template for NaviServer, and I take a look 
at how complex it is to write a small converter script.

> The AS project started this and I do not see any moves 
> there. The wiki-entered stuff is still there and nobody cares to
> get it into the CVS or get it translated to other off-line reading
> (man, html, pdf, etc) ?

Thats true. I think the effort stopped at the very beginning or halfway. But 
if only we had it in the Wiki! The problem is that writing documentation 
sucks, not writing the converter :-)))

> Who does which page? This is a simple matter of communication.
> I do not think that we need to divide this somehow. We are just
> a few people and it suffices to document as we go. I do not think
> that we will have much problems with that. A short email on the
> list telling: hey, I'j now do the ns_XZY or Ns_XZY() would do.

Ok. But we should have a complete list for C and TCL to know whats missing or 
when we are finished.
I started with TCL, but the list is not perfect:
http://naviserver.sourceforge.net/wiki/index.php/Examples:Commands

> I think that tagging the CVS now with 4.99.0 is perfectly OK as it would
> identify a body in CVS which is fixed and against which we can file
> bugs.

Ok, so we tag it after the macro insertion (or whatever solution) for the 
range headers?

> I would do the 5.0 after we've done all those nice new things like VFS
> support (advancing well, btw), fancier upload caps, integration of
> ns_cache,
> full support for byte-ranges, finalized docs etc. I would target this
> towards the end of the year.

ok.

Re: [naviserver-devel] Release/Docs

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

Am 04.07.2005 um 08:45 schrieb Bernd Eidenschink:

>
> Hi!
>
> I want to ask you for your opinion on a few things:
>
> a) Documentation
> AFAIK the status was to ask Andreas Kupries for (small?)  
> modification of the
> doctools to be able to make smart C-Function documentation.
> Zoran: Can you tell if your suggestions will be (or are) accepted?

This seems to lag behind (my fault) . Basically, the doctools is  
allright, the
only "limitation" is that you can't make one man-page describing more
than one C-API call. To get an idea, install Tcl and make:

   man Tcl_FSStat

and you will see that the *entire* Tcl-VFS API is documented in
one single man-page. Now, doctools can't make this. You'd need to
supply a man-page per-api-call.

But...

Having worked with that in last couple of days. I find it
*extremely* annoying. OOH, having conceptually related calls
all fit on one page is appealing. OTOH, if you frequently need
(man) access to a single call, then it is absolutely impractical
and annoying to flip pages and pages of docs just to locate the
call in question.

I would really suggest we make a simple (and doctools supported)
page-per-api-call approach. The doctools can already do that and
it will be easier to read and (perhaps) maintain.

The drawback is: number of files (will be quite large).
I think I can live with that.

>
> To me it would make sense to make the documentation effort now top  
> priority,
> regardless of the format. Later we can copy and paste it from  
> whatever source
> to our preferred target, but we should aim for the source now. Even  
> the fresh
> NaviServer commands are not documented and only available for the  
> skilled C
> developer (and see current discussion on AOLserver mailinglist).

Right.

>
> In the first step documentation must not be perfect and long, as  
> long as it
> respects some formal template documentation style and presents  
> things the way
> they work. Strategy?
> Two possible ways:
> (A)
> 1. Construct list of all current commands (C and TCL), mark the  
> deprecated
> ones.
> 2. Categorize commands.
> 3. We distribute documentation work among each other (small bunch  
> of commands
> for everyone; and we know who documents what command); and everyone  
> on the
> mailing list is a volunteer per se and likes to contribute :-)

This is not an option. This has to be done for the B. (below) as well!


> (B)
> - Update the '/doc' dir in CVS using current templates OR
> - Update the '/doc' dir in CVS using doctools OR
> - use Wiki for easy peer review and parse the Wiki structure later to
> transform the docs to whatever format (would be very simple step)

Current templates are in plan nroff and thus complex to
write. I would really use doctools for this purpose. doctools
have a very short learning curve (very similar to POD and very
Tcl-lish) so I believe everybody will be up and running after
glancing on a doctools page for a few minutes.

Wiki seems very nice for collaborative work but I do not
know if there is a wiki->doctools converter (doctools->wiki there is).
If we start hacking wiki, how would you convert this into some
other format? The AS project started this and I do not see any moves
there. The wiki-entered stuff is still there and nobody cares to
get it into the CVS or get it translated to other off-line reading
(man, html, pdf, etc) ?

Bottom line: I think the best way would be to make a template
for a C-API and Tcl-API call, then check-in this template for
every C/Tcl API calls in CVS, then take one at a time and fill
in the content. The CVS is a collaborative env, right?
Who does which page? This is a simple matter of communication.
I do not think that we need to divide this somehow. We are just
a few people and it suffices to document as we go. I do not think
that we will have much problems with that. A short email on the
list telling: hey, I'j now do the ns_XZY or Ns_XZY() would do.


>
> b) Intermediate-Release, Beta-Release
> This was also the intention for 4.99.0.
> There should be a release, downloadable!, so we have a visible  
> result of the
> current status and efforts. It should be clearly marked or named as
> intermediate or beta release, open for testing and reviewing.
> Along with a statement or Roadmap that says: This release will  
> become a
> default stable release - the next target is VFS, caching, etc.
> Do we want Version 5.0.0 to be the one with VFS, caching etc. or  
> the first
> stable release?

I think that tagging the CVS now with 4.99.0 is perfectly OK as it would
identify a body in CVS which is fixed and against which we can file  
bugs.

I would do the 5.0 after we've done all those nice new things like VFS
support (advancing well, btw), fancier upload caps, integration of  
ns_cache,
full support for byte-ranges, finalized docs etc. I would target this
towards the end of the year.

Zoran

[naviserver-devel] Release/Docs

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

Hi!

I want to ask you for your opinion on a few things:

a) Documentation
AFAIK the status was to ask Andreas Kupries for (small?) modification of the 
doctools to be able to make smart C-Function documentation. 
Zoran: Can you tell if your suggestions will be (or are) accepted?

To me it would make sense to make the documentation effort now top priority, 
regardless of the format. Later we can copy and paste it from whatever source 
to our preferred target, but we should aim for the source now. Even the fresh 
NaviServer commands are not documented and only available for the skilled C 
developer (and see current discussion on AOLserver mailinglist).

In the first step documentation must not be perfect and long, as long as it 
respects some formal template documentation style and presents things the way 
they work. Strategy?
Two possible ways:
(A)
1. Construct list of all current commands (C and TCL), mark the deprecated 
ones.
2. Categorize commands.
3. We distribute documentation work among each other (small bunch of commands 
for everyone; and we know who documents what command); and everyone on the 
mailing list is a volunteer per se and likes to contribute :-)
(B)
- Update the '/doc' dir in CVS using current templates OR
- Update the '/doc' dir in CVS using doctools OR
- use Wiki for easy peer review and parse the Wiki structure later to 
transform the docs to whatever format (would be very simple step)

b) Intermediate-Release, Beta-Release
This was also the intention for 4.99.0.
There should be a release, downloadable!, so we have a visible result of the 
current status and efforts. It should be clearly marked or named as 
intermediate or beta release, open for testing and reviewing.
Along with a statement or Roadmap that says: This release will become a 
default stable release - the next target is VFS, caching, etc.
Do we want Version 5.0.0 to be the one with VFS, caching etc. or the first 
stable release? 

What do you think?

Bernd.

Re: [Re: [naviserver-devel] Range requests]

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

Am 03.07.2005 um 23:04 schrieb vl...@cr...:

> It needs improvements i agree.
>
> i am on vaca! tion this week so you all decide without waiting for me.

I'd suggest #ifdef USE_BYTE_RANGES undefined by default. You can
temporarily tweak the Makefile to define it.

OTOH, what Stephen is suggesting makes sense. Stripout the range code,
make a release, add it back again. This way you'd be on the CVS-head as
you were before. Only the tagged release would have no ranges.

Zoran

Re: [naviserver-devel] Range requests

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

Am 03.07.2005 um 12:27 schrieb Stephen Deasey:
>
> I'm wondering if the best way forward is to back out the range code,
> make a quick release, then add it back for the next one along with the
> TclVFS stuff, file upload improvements, and hopefully my mythical
> caching changes, all of which are pretty invasive and potentially
> destabilizing.  What does everyone think?


Apropos a quick tagged release, yes!

As I see, Vlad is somehow dependent on the range's implementation
and I would not like to make his life complicated by taking out
the pieces. Perhaps a temporary #ifdef USE_BYTE_RANGES which would
be per-default undefined? This way he can just simply fix the
Makefile. I'm also using this with URLDECODE_RELAXED to be compatible
with (broken) urldecoder on AS...

Zoran

[Re: [naviserver-devel] Range requests]

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

<p>I was building range code to support streaming from VLC player and it does wirk. Also i have this code running on out public site and i see<br /> many range requests coming with asking partial contents so it is working in real life. The implementation is not complete but i've never seen in the logs multiple ranges. So for fastpath it looks working forme even in this form.</p><p>The funny thins that VLc does not handle range replies tself so this code did not help me with streaming.&nbsp;</p><p>&nbsp;Of course we can remove it but i think this is too conservative, without having it in the code there is notway to check how it works and have experience with it to complete it. Having this code in separate patches is not going to work, i use only CVS now and have no desire to have separate copies of the code. If this is just for release why it would harm it? It does no harm and handle subset of range requests pretty well.</p><p>It needs improvements i agree.</p><p>i am on vaca!
tion this week so you all decide without waiting for me.<br /> <br /> </p><p>-------- Original Message --------<br />To: nav...@li...<br />From: Stephen Deasey <br />Subject: [naviserver-devel] Range requests<br /><br />It doesn't make sense for the client to ask for a certain byte range <br />unless it already has the other bytes.  It needs to make sure that <br />it's not asking for the tail of a file which has changed in the <br />server. <br /> <br />The code doesn't handle If-Range.  If-Modified-Since is handled in the <br />existing code and returns early before the range code runs.  I don't <br />see how this range implementation could work in the real world.  <br />There's no tests for any of this. <br /> <br /> <br />Maybe a better way to handle multiple ranges is by using an iovec <br />struct.  We can pass the result directly to Ns_ConnSend() or something <br />similar. <br /> <br /> <br />The range code only handles fastpath requests, bu!
t it should probably <br />also handle stuff like ns_returnfp/ns_respond.  I don't see any reason <br />why it shouldn't also handle the fastpath cache. <br /> <br /> <br />The handling of response codes looks a little hairy.  How about if <br />ParseRange just returned the correct response code?  All error <br />checking should be moved inside that function.  At the moment <br />ParseRange handles some errors, the calling code others, which is <br />tricky to follow.  Also, it's extremely difficult to figure out what <br />the parsing code is doing. <br /> <br /> <br />AOLserver 4.5 has support for chunked responses.  We should probably <br />check to see how that might impact things. <br /> <br /> <br /> <br />I'm wondering if the best way forward is to back out the range code, <br />make a quick release, then add it back for the next one along with the <br />TclVFS stuff, file upload improvements, and hopefully my mythical <br />caching changes, all of which are pretty in!
vasive and potentially <br />destabilizing.  What does everyone think? <br /> <br /> <br /> <br /> <br /> <br />On 6/29/05, Vlad Seryakov  wrote: <br />&gt; Update of /cvsroot/naviserver/naviserver/nsd <br />&gt; In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4535/nsd <br />&gt; <br />&gt; Modified Files: <br />&gt;         fastpath.c <br />&gt; Log Message: <br />&gt; see ChangeLog <br />&gt; <br />&gt; <br />&gt; Index: fastpath.c <br />&gt; =================================================================== <br />&gt; RCS file: /cvsroot/naviserver/naviserver/nsd/fastpath.c,v <br />&gt; retrieving revision 1.9 <br />&gt; retrieving revision 1.10 <br />&gt; diff -C2 -d -r1.9 -r1.10 <br />&gt; *** fastpath.c  29 Jun 2005 23:27:50 -0000      1.9 <br />&gt; --- fastpath.c  30 Jun 2005 01:14:02 -0000      1.10 <br />&gt; *************** <br />&gt; *** 39,42 **** <br />&gt; --- 39,44 ---- <br />&gt;   NS_RCSID(&quot;@(#) $Header$&quot;); <br />&gt; <br />&gt; + #define MA!
X_RANGES      10 <br />&gt; + <br />&gt;   /* <br />&gt;    * The following structure defines the contents of a file <br />&gt; *************** <br />&gt; *** 61,66 **** <br />&gt;   static int FastReturn(NsServer *servPtr, Ns_Conn *conn, int status, <br />&gt;                         char *type, char *file, struct stat *stPtr); <br />&gt; ! static int ParseRange(Ns_Conn *conn, unsigned long size, <br />&gt; !                       unsigned long *offset1, unsigned long *offset2); <br />&gt; <br />&gt;   /* <br />&gt; --- 63,68 ---- <br />&gt;   static int FastReturn(NsServer *servPtr, Ns_Conn *conn, int status, <br />&gt;                         char *type, char *file, struct stat *stPtr); <br />&gt; ! static int ParseRange(Ns_Conn *conn, unsigned long size, unsigned long <br />*offsets, <br />&gt; !                       int offsets_size); <br />&gt; <br />&gt;   /* <br />&gt; *************** <br />&gt; *** 474,479 **** <br />&gt;   { <br />&gt;       int fd, new, nread; <b!
r />&gt; !     unsigned long size, offset1, offset2; <br />&gt; !     int result = NS_ERROR, range = NS_ERROR; <br />&gt;       char *key; <br />&gt;       Ns_Entry *entPtr; <br />&gt; --- 476,481 ---- <br />&gt;   { <br />&gt;       int fd, new, nread; <br />&gt; !     unsigned long size, offsets[MAX_RANGES*2]; <br />&gt; !     int result = NS_ERROR, ranges = 0; <br />&gt;       char *key; <br />&gt;       Ns_Entry *entPtr; <br />&gt; *************** <br />&gt; *** 520,537 **** <br />&gt;       size = stPtr-&gt;st_size; <br />&gt;       if (status == 200) { <br />&gt; !         range = ParseRange(conn, stPtr-&gt;st_size, &amp;offset1,  <br />&gt;       } <br />&gt; !     if (range != NS_ERROR) { <br />&gt; !         if (offset1 &gt; offset2) { <br />&gt; !             /* 416 Requested Range Not Satisfiable */ <br />&gt; !             Ns_ConnPrintfHeaders(conn, &quot;Content-Range&quot;, &quot;bytes */%lu&quot;, <br />&gt; !                                stPtr-&gt;st_size);!
 <br />&gt; !             Ns_ConnSetRequiredHeaders(conn, type, (int) stPtr-&gt;st_size); <br />&gt; !             return Ns_ConnFlushHeaders(conn, 416); <br />&gt; !         } <br />&gt;           /* Continue with returning a portion of the file */ <br />&gt;           Ns_ConnPrintfHeaders(conn, &quot;Content-Range&quot;, &quot;bytes %lu-%lu/%lu&quot;, <br />&gt; !                               offset1, offset2, stPtr-&gt;st_size); <br />&gt; !         size = (offset2 - offset1) + 1; <br />&gt;           /* 206 Partial Content */ <br />&gt;           status = 206; <br />&gt; --- 522,539 ---- <br />&gt;       size = stPtr-&gt;st_size; <br />&gt;       if (status == 200) { <br />&gt; !         ranges = ParseRange(conn, stPtr-&gt;st_size, offsets, MAX_RANGES*2); <br />&gt;       } <br />&gt; !     if (ranges == -1) { <br />&gt; !         /* 416 Requested Range Not Satisfiable */ <br />&gt; !         Ns_ConnPrintfHeaders(conn, &quot;Content-Range&quot;, &quot;bytes */%lu&quot;,!
 <br />&gt; !                              stPtr-&gt;st_size); <br />&gt; !         Ns_ConnSetRequiredHeaders(conn, type, (int) stPtr-&gt;st_size); <br />&gt; !         return Ns_ConnFlushHeaders(conn, 416); <br />&gt; !     } <br />&gt; !     if (ranges == 1) { <br />&gt;           /* Continue with returning a portion of the file */ <br />&gt;           Ns_ConnPrintfHeaders(conn, &quot;Content-Range&quot;, &quot;bytes %lu-%lu/%lu&quot;, <br />&gt; !                              offsets[0], offsets[1], stPtr-&gt;st_size); <br />&gt; !         size = (offsets[1] - offsets[0]) + 1; <br />&gt;           /* 206 Partial Content */ <br />&gt;           status = 206; <br />&gt; *************** <br />&gt; *** 540,544 **** <br />&gt;       if (servPtr-&gt;fastpath.cache == NULL <br />&gt;           || stPtr-&gt;st_size &gt; servPtr-&gt;fastpath.cachemaxentry <br />&gt; !         || range == NS_OK) { <br />&gt; <br />&gt;           /* <br />&gt; --- 542,546 ---- <br />&gt;       if (s!
ervPtr-&gt;fastpath.cache == NULL <br />&gt;           || stPtr-&gt;st_size &gt; servPtr-&gt;fastpath.cachemaxentry <br />&gt; !         || ranges == 1) { <br />&gt; <br />&gt;           /* <br />&gt; *************** <br />&gt; *** 552,557 **** <br />&gt;               &amp;&amp; NsMemMap(file, stPtr-&gt;st_size, NS_MMAP_READ, &amp;fmap) == NS_OK) <br />{ <br />&gt;               char *maddr = fmap.addr; <br />&gt; !             if (range == NS_OK) { <br />&gt; !                 maddr += offset1; <br />&gt;               } <br />&gt;               result = Ns_ConnReturnData(conn,status, maddr, size, type); <br />&gt; --- 554,559 ---- <br />&gt;               &amp;&amp; NsMemMap(file, stPtr-&gt;st_size, NS_MMAP_READ, &amp;fmap) == NS_OK) <br />{ <br />&gt;               char *maddr = fmap.addr; <br />&gt; !             if (ranges &gt; 0) { <br />&gt; !                 maddr += offsets[0]; <br />&gt;               } <br />&gt;               result = Ns_ConnReturnData(conn,stat!
us, maddr, size, type); <br />&gt; *************** <br />&gt; *** 564,569 **** <br />&gt;                   goto notfound; <br />&gt;               } <br />&gt; !             if (range == NS_OK) { <br />&gt; !                 lseek(fd, offset1, SEEK_SET); <br />&gt;               } <br />&gt;               result = Ns_ConnReturnOpenFd(conn, status, type, fd, size); <br />&gt; --- 566,571 ---- <br />&gt;                   goto notfound; <br />&gt;               } <br />&gt; !             if (ranges &gt; 0) { <br />&gt; !                 lseek(fd, offsets[0], SEEK_SET); <br />&gt;               } <br />&gt;               result = Ns_ConnReturnOpenFd(conn, status, type, fd, size); <br />&gt; *************** <br />&gt; *** 690,694 **** <br />&gt;    * <br />&gt;    * Results: <br />&gt; !  *      NS_OK or NS_ERROR <br />&gt;    * <br />&gt;    * Side effects: <br />&gt; --- 692,696 ---- <br />&gt;    * <br />&gt;    * Results: <br />&gt; !  *      -1 on error, number of byte ran!
ges parsed <br />&gt;    * <br />&gt;    * Side effects: <br />&gt; *************** <br />&gt; *** 699,755 **** <br />&gt; <br />&gt;   static int <br />&gt; ! ParseRange(Ns_Conn *conn, unsigned long size, <br />&gt; !                unsigned long *offset1, unsigned long *offset2) <br />&gt;   { <br />&gt;       char *range; <br />&gt; <br />&gt; !     *offset1 = *offset2 = 0; <br />&gt; <br />&gt; !     if ((range = Ns_SetIGet(conn-&gt;headers, &quot;Range&quot;)) != NULL <br />&gt; !         &amp;&amp; (range = strstr(range,&quot;bytes=&quot;)) != NULL) { <br />&gt; !         range += 6; <br />&gt; !         /* Multiple ranges are not supported yet */ <br />&gt; !         if (strchr(range,',') != NULL) { <br />&gt; !             return NS_ERROR; <br />&gt; !         } <br />&gt;           if (isdigit(*range)) { <br />&gt; !             *offset1 = atol(range); <br />&gt;               while (isdigit(*range)) range++; <br />&gt;               if (*range == '-') { <br />&gt; !
                  range++; <br />&gt;                   if (!isdigit(*range)) { <br />&gt; !                     if (*range != '\0') { <br />&gt; !                         return NS_ERROR; <br />&gt; !                     } <br />&gt; !                     *offset2 = size - 1; <br />&gt;                   } else { <br />&gt; !                     *offset2 = atol(range); <br />&gt; !                     if (*offset1 &gt; *offset2) { <br />&gt; !                         return NS_ERROR; <br />&gt;                       } <br />&gt; !                     if (*offset2 &gt;= size) { <br />&gt; !                         *offset2 = size - 1; <br />&gt;                       } <br />&gt;                   } <br />&gt; !                 return NS_OK; <br />&gt; !             } else { <br />&gt; !                 return NS_ERROR; <br />&gt;               } <br />&gt;           } else if (*range == '-') { <br />&gt;               range++; <br />&gt;               if (!isdigit(*range)) !
{ <br />&gt; !                 return NS_ERROR; <br />&gt;               } <br />&gt; !             *offset2 = atol(range); <br />&gt; !             if (*offset2 &gt; size) { <br />&gt; !                 *offset2 = size; <br />&gt;               } <br />&gt;               /* Size from the end requested, convert into offset */ <br />&gt; !             *offset1 = size - *offset2; <br />&gt; !             *offset2 = *offset1 + *offset2 - 1; <br />&gt; !             return NS_OK; <br />&gt;           } <br />&gt;       } <br />&gt; !     return NS_ERROR; <br />&gt;   } <br />&gt; <br />&gt; --- 701,780 ---- <br />&gt; <br />&gt;   static int <br />&gt; ! ParseRange(Ns_Conn *conn, unsigned long size, unsigned long *offsets, <br />&gt; !            int offsets_size) <br />&gt;   { <br />&gt; +     int count = 0; <br />&gt;       char *range; <br />&gt; <br />&gt; !     if ((range = Ns_SetIGet(conn-&gt;headers, &quot;Range&quot;)) == NULL <br />&gt; !         || (range = strstr(ran!
ge,&quot;bytes=&quot;)) == NULL) { <br />&gt; !         return 0; <br />&gt; !     } <br />&gt; !     range += 6; <br />&gt; !     memset(offsets,0,sizeof(unsigned long)*offsets_size); <br />&gt; <br />&gt; !     while(*range &amp;&amp; count            if (isdigit(*range)) { <br />&gt; !             offsets[count] = atol(range); <br />&gt;               while (isdigit(*range)) range++; <br />&gt;               if (*range == '-') { <br />&gt;                   range++; <br />&gt;                   if (!isdigit(*range)) { <br />&gt; !                     offsets[count+1] = size - 1; <br />&gt;                   } else { <br />&gt; !                     offsets[count+1] = atol(range); <br />&gt; !                     if (offsets[count] &gt; offsets[count+1]) { <br />&gt; !                         return 0; <br />&gt;                       } <br />&gt; !                     if (offsets[count+1] &gt;= size) { <br />&gt; !                         offsets[count+1] = size - 1; <br !
/>&gt;                       } <br />&gt; +                     while (isdigit(*range)) range++; <br />&gt;                   } <br />&gt; !                 switch (*range) { <br />&gt; !                  case ',': <br />&gt; !                      range++; <br />&gt; !                  case '\0': <br />&gt; !                      break; <br />&gt; !                  default: <br />&gt; !                      return 0; <br />&gt; !                 } <br />&gt; !                 if (offsets[count] &gt; offsets[count+1]) { <br />&gt; !                     return -1; <br />&gt; !                 } <br />&gt; !                 count += 2; <br />&gt; !                 continue; <br />&gt;               } <br />&gt;           } else if (*range == '-') { <br />&gt;               range++; <br />&gt;               if (!isdigit(*range)) { <br />&gt; !                 return 0; <br />&gt;               } <br />&gt; !             offsets[count+1] = atol(range); <br />&gt; !             !
if (offsets[count+1] &gt; size) { <br />&gt; !                 offsets[count+1] = size; <br />&gt;               } <br />&gt;               /* Size from the end requested, convert into offset */ <br />&gt; !             offsets[count] = size - offsets[count+1]; <br />&gt; !             offsets[count+1] = offsets[count] + offsets[count+1] - 1; <br />&gt; !             while (isdigit(*range)) range++; <br />&gt; !             switch (*range) { <br />&gt; !              case ',': <br />&gt; !                  range++; <br />&gt; !              case '\0': <br />&gt; !                  break; <br />&gt; !              default: <br />&gt; !                  return 0; <br />&gt; !             } <br />&gt; !             if (offsets[count] &gt; offsets[count+1]) { <br />&gt; !                 return -1; <br />&gt; !             } <br />&gt; !             count += 2; <br />&gt; !             continue; <br />&gt;           } <br />&gt; +         /* Invalid syntax */ <br />&gt; +       !
  return 0; <br />&gt;       } <br />&gt; !     return count/2; <br />&gt;   } <br /> <br /> <br />------------------------------------------------------- <br />SF.Net email is sponsored by: Discover Easy Linux Migration Strategies <br />from IBM. Find simple to follow Roadmaps, straightforward articles, <br />informative Webcasts and more! Get everything you need to get up to <br />speed, fast. http://ads.osdn.com/?ad_idt77&amp;alloc_id492&amp;op&Igrave;k <br />_______________________________________________ <br />naviserver-devel mailing list <br />nav...@li... <br />https://lists.sourceforge.net/lists/listinfo/naviserver-devel <br /><br /></p>

[naviserver-devel] DOAP

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

I wrote a small 'naviserver.rdf' xml-like file in DOAP vocabulary 
(http://usefulinc.com/doap)

Stephen suggested DOAP some months ago for modules. It's nice to describe the 
basics of a projects, (DOAP aka "Description of a Project").

I don't know how widely adopted that DOAP thing is, but it might not harm. If 
it's ok for you I would commit it to the same location as NEWS	and Changelog.

Re: [naviserver-devel] ns_cp and friends?

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

Am 03.07.2005 um 14:01 schrieb Bernd Eidenschink:

> Hi Zoran,
>
>
>>   ns_cp              (file copy)
>>   ns_mkdir           (file mkdir)
>>   ns_rmdir           (file delete)
>>   ns_unlink          (file delete)
>>   ns_normalizepath   (file normalize)
>>   ns_link            (file link -hard)
>>   ns_symlink         (file link -symbolic)
>>   ns_rename          (file rename)
>>
>> I do not know why we would like to maintain those
>> commands when Tcl is already giving us a good and
>> maintained interface to the needed functionalitly?
>>
>
> What was the reason the commands exist at all? :-)
>

I think this is left-over from Tcl7.x and AS 2.0 or earlier.

>
>> Now, were do you want to go today?
>>
>
> I vote for Stephens tcl/compat.tcl way. A log notice would be nice  
> to track
> down sideeffects of the change, just in case.

Then be it. I will make compat.tcl wrappers and emit
the:

   ns_log warning "foo call is deprecated: use bar instead"

Zoran

Re: [naviserver-devel] ns_cp and friends?

[Bernd E. <b.e...@ki...>]

Hi Zoran,

>   ns_cp              (file copy)
>   ns_mkdir           (file mkdir)
>   ns_rmdir           (file delete)
>   ns_unlink          (file delete)
>   ns_normalizepath   (file normalize)
>   ns_link            (file link -hard)
>   ns_symlink         (file link -symbolic)
>   ns_rename          (file rename)
>
> I do not know why we would like to maintain those
> commands when Tcl is already giving us a good and
> maintained interface to the needed functionalitly?

What was the reason the commands exist at all? :-)

> Now, were do you want to go today?

I vote for Stephens tcl/compat.tcl way. A log notice would be nice to track 
down sideeffects of the change, just in case.

Re: [naviserver-devel] Range requests

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

> I'm wondering if the best way forward is to back out the range code,
> make a quick release, then add it back for the next one along with the
> TclVFS stuff, file upload improvements, and hopefully my mythical
> caching changes, all of which are pretty invasive and potentially
> destabilizing.  What does everyone think?

Having a (quick or not quick) first official release would surely make it 
easier to use it on production systems, report bugs etc.

Re: [naviserver-devel] hey hey wiki

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

Hi Stephen,

> I was thinking the wiki might be best suited to task-specific
> documentation?  For example, rather than list all commands and give an
> example of each, we might have a page 'Returning Data' which shows how
> to use ns_return, ns_returnfile, ..., how to write headers and stream
> content with ns_write, how to choose between them, etc.  Then we might
> have a page called 'Performance Tuning' which would describe which
> config file settings affect performance, settings for your OS, how to
> use the stats interface for gathering data, etc.
>
> The formal API documentation in CVS will be the first place to go when
> you have a specific question about how the server works.  When you
> have a goal in mind -- tune the server, write a form that accepts file
> uploads, set up virtual hosts -- you'll read an article on the wiki.
>
> Makes sense?

Think it would be a good combination to combine the two approaches!

My suggestion was to present a (somehow) complete list of commands including 
their categorization as kind of a showroom of possibilities.
If they are adequately grouped 
* new users can find commands they need in a context
* learn about more and other ways to do things
And finally I found that lots of good advice, corrections and discussions 
comes from users using the commands to solve individual problems: Just take a 
look at the commented PHP and MySQL Documentation!
If that would happen here it would be a great bonus!

With the wiki approach it's very easy to link to pages that fit for your 
suggestion of Best Practices and HowTo's, e.g. we could do

...
* ns_returnfile: <Link to 'Returning Data'>, <Link to smth. else>, ...
...
* ns_write: <Link to smth. else>, <Link to 'Returning Data'>, ...
...

So everyone could get the use of commands in different or similar contexts.

[naviserver-devel] Range requests

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

It doesn't make sense for the client to ask for a certain byte range
unless it already has the other bytes.  It needs to make sure that
it's not asking for the tail of a file which has changed in the
server.

The code doesn't handle If-Range.  If-Modified-Since is handled in the
existing code and returns early before the range code runs.  I don't
see how this range implementation could work in the real world.=20
There's no tests for any of this.


Maybe a better way to handle multiple ranges is by using an iovec
struct.  We can pass the result directly to Ns_ConnSend() or something
similar.


The range code only handles fastpath requests, but it should probably
also handle stuff like ns_returnfp/ns_respond.  I don't see any reason
why it shouldn't also handle the fastpath cache.


The handling of response codes looks a little hairy.  How about if
ParseRange just returned the correct response code?  All error
checking should be moved inside that function.  At the moment
ParseRange handles some errors, the calling code others, which is
tricky to follow.  Also, it's extremely difficult to figure out what
the parsing code is doing.


AOLserver 4.5 has support for chunked responses.  We should probably
check to see how that might impact things.



I'm wondering if the best way forward is to back out the range code,
make a quick release, then add it back for the next one along with the
TclVFS stuff, file upload improvements, and hopefully my mythical
caching changes, all of which are pretty invasive and potentially
destabilizing.  What does everyone think?





On 6/29/05, Vlad Seryakov <ser...@us...> wrote:
> Update of /cvsroot/naviserver/naviserver/nsd
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4535/nsd
>=20
> Modified Files:
>         fastpath.c
> Log Message:
> see ChangeLog
>=20
>=20
> Index: fastpath.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/naviserver/naviserver/nsd/fastpath.c,v
> retrieving revision 1.9
> retrieving revision 1.10
> diff -C2 -d -r1.9 -r1.10
> *** fastpath.c  29 Jun 2005 23:27:50 -0000      1.9
> --- fastpath.c  30 Jun 2005 01:14:02 -0000      1.10
> ***************
> *** 39,42 ****
> --- 39,44 ----
>   NS_RCSID("@(#) $Header$");
>=20
> + #define MAX_RANGES      10
> +
>   /*
>    * The following structure defines the contents of a file
> ***************
> *** 61,66 ****
>   static int FastReturn(NsServer *servPtr, Ns_Conn *conn, int status,
>                         char *type, char *file, struct stat *stPtr);
> ! static int ParseRange(Ns_Conn *conn, unsigned long size,
> !                       unsigned long *offset1, unsigned long *offset2);
>=20
>   /*
> --- 63,68 ----
>   static int FastReturn(NsServer *servPtr, Ns_Conn *conn, int status,
>                         char *type, char *file, struct stat *stPtr);
> ! static int ParseRange(Ns_Conn *conn, unsigned long size, unsigned long =
*offsets,
> !                       int offsets_size);
>=20
>   /*
> ***************
> *** 474,479 ****
>   {
>       int fd, new, nread;
> !     unsigned long size, offset1, offset2;
> !     int result =3D NS_ERROR, range =3D NS_ERROR;
>       char *key;
>       Ns_Entry *entPtr;
> --- 476,481 ----
>   {
>       int fd, new, nread;
> !     unsigned long size, offsets[MAX_RANGES*2];
> !     int result =3D NS_ERROR, ranges =3D 0;
>       char *key;
>       Ns_Entry *entPtr;
> ***************
> *** 520,537 ****
>       size =3D stPtr->st_size;
>       if (status =3D=3D 200) {
> !         range =3D ParseRange(conn, stPtr->st_size, &offset1, &offset2);
>       }
> !     if (range !=3D NS_ERROR) {
> !         if (offset1 > offset2) {
> !             /* 416 Requested Range Not Satisfiable */
> !             Ns_ConnPrintfHeaders(conn, "Content-Range", "bytes */%lu",
> !                                stPtr->st_size);
> !             Ns_ConnSetRequiredHeaders(conn, type, (int) stPtr->st_size)=
;
> !             return Ns_ConnFlushHeaders(conn, 416);
> !         }
>           /* Continue with returning a portion of the file */
>           Ns_ConnPrintfHeaders(conn, "Content-Range", "bytes %lu-%lu/%lu"=
,
> !                               offset1, offset2, stPtr->st_size);
> !         size =3D (offset2 - offset1) + 1;
>           /* 206 Partial Content */
>           status =3D 206;
> --- 522,539 ----
>       size =3D stPtr->st_size;
>       if (status =3D=3D 200) {
> !         ranges =3D ParseRange(conn, stPtr->st_size, offsets, MAX_RANGES=
*2);
>       }
> !     if (ranges =3D=3D -1) {
> !         /* 416 Requested Range Not Satisfiable */
> !         Ns_ConnPrintfHeaders(conn, "Content-Range", "bytes */%lu",
> !                              stPtr->st_size);
> !         Ns_ConnSetRequiredHeaders(conn, type, (int) stPtr->st_size);
> !         return Ns_ConnFlushHeaders(conn, 416);
> !     }
> !     if (ranges =3D=3D 1) {
>           /* Continue with returning a portion of the file */
>           Ns_ConnPrintfHeaders(conn, "Content-Range", "bytes %lu-%lu/%lu"=
,
> !                              offsets[0], offsets[1], stPtr->st_size);
> !         size =3D (offsets[1] - offsets[0]) + 1;
>           /* 206 Partial Content */
>           status =3D 206;
> ***************
> *** 540,544 ****
>       if (servPtr->fastpath.cache =3D=3D NULL
>           || stPtr->st_size > servPtr->fastpath.cachemaxentry
> !         || range =3D=3D NS_OK) {
>=20
>           /*
> --- 542,546 ----
>       if (servPtr->fastpath.cache =3D=3D NULL
>           || stPtr->st_size > servPtr->fastpath.cachemaxentry
> !         || ranges =3D=3D 1) {
>=20
>           /*
> ***************
> *** 552,557 ****
>               && NsMemMap(file, stPtr->st_size, NS_MMAP_READ, &fmap) =3D=
=3D NS_OK) {
>               char *maddr =3D fmap.addr;
> !             if (range =3D=3D NS_OK) {
> !                 maddr +=3D offset1;
>               }
>               result =3D Ns_ConnReturnData(conn,status, maddr, size, type=
);
> --- 554,559 ----
>               && NsMemMap(file, stPtr->st_size, NS_MMAP_READ, &fmap) =3D=
=3D NS_OK) {
>               char *maddr =3D fmap.addr;
> !             if (ranges > 0) {
> !                 maddr +=3D offsets[0];
>               }
>               result =3D Ns_ConnReturnData(conn,status, maddr, size, type=
);
> ***************
> *** 564,569 ****
>                   goto notfound;
>               }
> !             if (range =3D=3D NS_OK) {
> !                 lseek(fd, offset1, SEEK_SET);
>               }
>               result =3D Ns_ConnReturnOpenFd(conn, status, type, fd, size=
);
> --- 566,571 ----
>                   goto notfound;
>               }
> !             if (ranges > 0) {
> !                 lseek(fd, offsets[0], SEEK_SET);
>               }
>               result =3D Ns_ConnReturnOpenFd(conn, status, type, fd, size=
);
> ***************
> *** 690,694 ****
>    *
>    * Results:
> !  *      NS_OK or NS_ERROR
>    *
>    * Side effects:
> --- 692,696 ----
>    *
>    * Results:
> !  *      -1 on error, number of byte ranges parsed
>    *
>    * Side effects:
> ***************
> *** 699,755 ****
>=20
>   static int
> ! ParseRange(Ns_Conn *conn, unsigned long size,
> !                unsigned long *offset1, unsigned long *offset2)
>   {
>       char *range;
>=20
> !     *offset1 =3D *offset2 =3D 0;
>=20
> !     if ((range =3D Ns_SetIGet(conn->headers, "Range")) !=3D NULL
> !         && (range =3D strstr(range,"bytes=3D")) !=3D NULL) {
> !         range +=3D 6;
> !         /* Multiple ranges are not supported yet */
> !         if (strchr(range,',') !=3D NULL) {
> !             return NS_ERROR;
> !         }
>           if (isdigit(*range)) {
> !             *offset1 =3D atol(range);
>               while (isdigit(*range)) range++;
>               if (*range =3D=3D '-') {
>                   range++;
>                   if (!isdigit(*range)) {
> !                     if (*range !=3D '\0') {
> !                         return NS_ERROR;
> !                     }
> !                     *offset2 =3D size - 1;
>                   } else {
> !                     *offset2 =3D atol(range);
> !                     if (*offset1 > *offset2) {
> !                         return NS_ERROR;
>                       }
> !                     if (*offset2 >=3D size) {
> !                         *offset2 =3D size - 1;
>                       }
>                   }
> !                 return NS_OK;
> !             } else {
> !                 return NS_ERROR;
>               }
>           } else if (*range =3D=3D '-') {
>               range++;
>               if (!isdigit(*range)) {
> !                 return NS_ERROR;
>               }
> !             *offset2 =3D atol(range);
> !             if (*offset2 > size) {
> !                 *offset2 =3D size;
>               }
>               /* Size from the end requested, convert into offset */
> !             *offset1 =3D size - *offset2;
> !             *offset2 =3D *offset1 + *offset2 - 1;
> !             return NS_OK;
>           }
>       }
> !     return NS_ERROR;
>   }
>=20
> --- 701,780 ----
>=20
>   static int
> ! ParseRange(Ns_Conn *conn, unsigned long size, unsigned long *offsets,
> !            int offsets_size)
>   {
> +     int count =3D 0;
>       char *range;
>=20
> !     if ((range =3D Ns_SetIGet(conn->headers, "Range")) =3D=3D NULL
> !         || (range =3D strstr(range,"bytes=3D")) =3D=3D NULL) {
> !         return 0;
> !     }
> !     range +=3D 6;
> !     memset(offsets,0,sizeof(unsigned long)*offsets_size);
>=20
> !     while(*range && count < offsets_size-1) {
>           if (isdigit(*range)) {
> !             offsets[count] =3D atol(range);
>               while (isdigit(*range)) range++;
>               if (*range =3D=3D '-') {
>                   range++;
>                   if (!isdigit(*range)) {
> !                     offsets[count+1] =3D size - 1;
>                   } else {
> !                     offsets[count+1] =3D atol(range);
> !                     if (offsets[count] > offsets[count+1]) {
> !                         return 0;
>                       }
> !                     if (offsets[count+1] >=3D size) {
> !                         offsets[count+1] =3D size - 1;
>                       }
> +                     while (isdigit(*range)) range++;
>                   }
> !                 switch (*range) {
> !                  case ',':
> !                      range++;
> !                  case '\0':
> !                      break;
> !                  default:
> !                      return 0;
> !                 }
> !                 if (offsets[count] > offsets[count+1]) {
> !                     return -1;
> !                 }
> !                 count +=3D 2;
> !                 continue;
>               }
>           } else if (*range =3D=3D '-') {
>               range++;
>               if (!isdigit(*range)) {
> !                 return 0;
>               }
> !             offsets[count+1] =3D atol(range);
> !             if (offsets[count+1] > size) {
> !                 offsets[count+1] =3D size;
>               }
>               /* Size from the end requested, convert into offset */
> !             offsets[count] =3D size - offsets[count+1];
> !             offsets[count+1] =3D offsets[count] + offsets[count+1] - 1;
> !             while (isdigit(*range)) range++;
> !             switch (*range) {
> !              case ',':
> !                  range++;
> !              case '\0':
> !                  break;
> !              default:
> !                  return 0;
> !             }
> !             if (offsets[count] > offsets[count+1]) {
> !                 return -1;
> !             }
> !             count +=3D 2;
> !             continue;
>           }
> +         /* Invalid syntax */
> +         return 0;
>       }
> !     return count/2;
>   }

Re: [naviserver-devel] hey hey wiki

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

On 6/29/05, Bernd Eidenschink <eid...@we...> wrote:
>=20
> Hi NaviCoders,
>=20
> I played a bit with the Wiki and started to add something to a Documentat=
ion
> section. Would be cool if you could just take a quick look the next days =
(no
> hurry) and rearrange/debug what you think fits better or is more logical.


Looks good.  Thanks!

I was thinking the wiki might be best suited to task-specific
documentation?  For example, rather than list all commands and give an
example of each, we might have a page 'Returning Data' which shows how
to use ns_return, ns_returnfile, ..., how to write headers and stream
content with ns_write, how to choose between them, etc.  Then we might
have a page called 'Performance Tuning' which would describe which
config file settings affect performance, settings for your OS, how to
use the stats interface for gathering data, etc.

The formal API documentation in CVS will be the first place to go when
you have a specific question about how the server works.  When you
have a goal in mind -- tune the server, write a form that accepts file
uploads, set up virtual hosts -- you'll read an article on the wiki.

Makes sense?


> Stephen, do you know how to make backups from that MySQL-stuff the easy w=
ay?


You have to login to the SF shell server using ssh and dump the db.=20
SF don't like you to leave the dump lying around on the server, so
maybe a couple of cron jobs that dump and then cleanup an hour later,
allowing project admins to scp the contents would do the trick?

Need to figure this out and create an 'Admin' page on the wiki...

Re: [naviserver-devel] NS_GNUC_NONNULL on Windows?

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

On 6/30/05, Ibrahim Tannir <it...@we...> wrote:
> Zoran Vasiljevic wrote:
> >
> > Am 30.06.2005 um 00:47 schrieb Stephen Deasey:
> >
> >> NS_GNUC_NONNULL is only used in the nscheck.h header because I haven't
> >> had time to sprinkle it anywhere else  :-)   I think it's a pretty
> >> useful feature, so I'd like to keep it.
> >>
> >> Macro varargs are not supported by any Microsoft compiler?
> >>
> >
> > No.
>=20
> I checked again. No. Neiter does the manual mention it nor does
> the latest compiler accept it.
>=20
> >> If you really can't find another solution, then redefining
> >> NS_GNUC_NONNULL to take a single arg should work.  It can be called
> >> multiple times, one for each non-null function argument.  But this is
> >> ugly, so prefer to keep the varargs if you can.
> >
> >
> > Ugly or not, this is what we have and must stick to it.
> > But, this would mean if you start to utilize the macro
> > in generic code, you'd have to use it with only one arg, right?
>=20
> There is this old trick - using double parenthesis - to cope with
> this problem in the code, e.g.
>=20
> #define MYPRINTF(x) printf x
>=20
> MYPRINTF((stderr, "%s\n", "abc"));


I can can live with that.

Re: [naviserver-devel] ns_cp and friends?

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

On 7/3/05, Zoran Vasiljevic <zv...@ar...> wrote:
> Hi!
>=20
> I'm currently after implemeting the Tcl VFS layer
> in the code and I stumbled in some dusty code corners...
>=20
> Following commands I never actually used and their
> functionality is already well-done by the Tcl alone:
>=20
>   ns_cp              (file copy)
>   ns_mkdir           (file mkdir)
>   ns_rmdir           (file delete)
>   ns_unlink          (file delete)
>   ns_normalizepath   (file normalize)
>   ns_link            (file link -hard)
>   ns_symlink         (file link -symbolic)
>   ns_rename          (file rename)
>=20
> I do not know why we would like to maintain those
> commands when Tcl is already giving us a good and
> maintained interface to the needed functionalitly?
>=20
> I have some ideas:
>=20
> A.
> I could just trash those commands (some of you
> will probably not like it, although this would be
> the best option).
>=20
> B.
> I could re-route those calls to their corresponding
> Tcl commands by a means of a tiny wrapper and emit
> a warning message in the log file that those commands
> are deprecated.
>=20
> C.
> I could leave the internal code as-is and just emit
> the warning message in the log that those commands
> are deprecated.
>=20
> D. I could throw error on those commands telling the
> user to use the Tcl equivalent.
>=20
> E.
> I could leave them as-is i.e. they will not be VFS savvy.
>=20
> Now, were do you want to go today?
> Zoran


Remove them and add simple wrappers in tcl/compat.tcl

[naviserver-devel] ns_cp and friends?

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

Hi!

I'm currently after implemeting the Tcl VFS layer
in the code and I stumbled in some dusty code corners...

Following commands I never actually used and their
functionality is already well-done by the Tcl alone:

  ns_cp              (file copy)
  ns_mkdir           (file mkdir)
  ns_rmdir           (file delete)
  ns_unlink          (file delete)
  ns_normalizepath   (file normalize)
  ns_link            (file link -hard)
  ns_symlink         (file link -symbolic)
  ns_rename          (file rename)

I do not know why we would like to maintain those
commands when Tcl is already giving us a good and
maintained interface to the needed functionalitly?

I have some ideas:

A.
I could just trash those commands (some of you
will probably not like it, although this would be
the best option).

B.
I could re-route those calls to their corresponding
Tcl commands by a means of a tiny wrapper and emit
a warning message in the log file that those commands
are deprecated.

C.
I could leave the internal code as-is and just emit
the warning message in the log that those commands
are deprecated.

D. I could throw error on those commands telling the
user to use the Tcl equivalent.

E.
I could leave them as-is i.e. they will not be VFS savvy.

Now, were do you want to go today?
Zoran

Re: [naviserver-devel] NS_GNUC_NONNULL on Windows?

[Ibrahim T. <it...@we...>]

Zoran Vasiljevic wrote:
> 
> Am 30.06.2005 um 00:47 schrieb Stephen Deasey:
> 
>> NS_GNUC_NONNULL is only used in the nscheck.h header because I haven't
>> had time to sprinkle it anywhere else  :-)   I think it's a pretty
>> useful feature, so I'd like to keep it.
>>
>> Macro varargs are not supported by any Microsoft compiler?
>>
> 
> No.

I checked again. No. Neiter does the manual mention it nor does 
the latest compiler accept it.

>> If you really can't find another solution, then redefining
>> NS_GNUC_NONNULL to take a single arg should work.  It can be called
>> multiple times, one for each non-null function argument.  But this is
>> ugly, so prefer to keep the varargs if you can.
> 
> 
> Ugly or not, this is what we have and must stick to it.
> But, this would mean if you start to utilize the macro
> in generic code, you'd have to use it with only one arg, right?

There is this old trick - using double parenthesis - to cope with 
this problem in the code, e.g.

#define MYPRINTF(x) printf x

MYPRINTF((stderr, "%s\n", "abc"));

> 
> Zoran

Ibrahim

Re: [naviserver-devel] NS_GNUC_NONNULL on Windows?

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

Am 30.06.2005 um 00:47 schrieb Stephen Deasey:

> NS_GNUC_NONNULL is only used in the nscheck.h header because I haven't
> had time to sprinkle it anywhere else  :-)   I think it's a pretty
> useful feature, so I'd like to keep it.
>
> Macro varargs are not supported by any Microsoft compiler?
>

No.

> If you really can't find another solution, then redefining
> NS_GNUC_NONNULL to take a single arg should work.  It can be called
> multiple times, one for each non-null function argument.  But this is
> ugly, so prefer to keep the varargs if you can.

Ugly or not, this is what we have and must stick to it.
But, this would mean if you start to utilize the macro
in generic code, you'd have to use it with only one arg, right?

Zoran

Re: [naviserver-devel] NS_GNUC_NONNULL on Windows?

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

NS_GNUC_NONNULL is only used in the nscheck.h header because I haven't
had time to sprinkle it anywhere else  :-)   I think it's a pretty
useful feature, so I'd like to keep it.

Macro varargs are not supported by any Microsoft compiler?

If you really can't find another solution, then redefining
NS_GNUC_NONNULL to take a single arg should work.  It can be called
multiple times, one for each non-null function argument.  But this is
ugly, so prefer to keep the varargs if you can.



On 6/29/05, Ibrahim Tannir <it...@ar...> wrote:
> Hello everybody,
>=20
> Please excuse my ignorance in the netickette and use of SF and
> the naviserver project - and please bear with me - I'm still
> learning.
>=20
> To Zoran's request (motivated by myself):
> Since NS_GNUC_NONNULL is not used anywhere else but in nscheck.h
> itself and only with GNUC, it suffices to remove it from the
> non-GNUC part to make it compilable for Windows.
>=20
> Is it OK with you if I do so?
>=20
> Greetings,
> Ibrahim
>=20
>=20
>=20
> Zoran Vasiljevic wrote:
> > Hi frieds,
> >
> > There seems to be a problem with NS_GNUC_NONNULL macro definition
> > when compiling the code on Windows. This is how/where this beast
> > is defined:
> >
> > #if __GNUC_PREREQ(3,3)
> > # define NS_GNUC_NONNULL(...) __attribute__((__nonnull__(__VA_ARGS__)))
> > # define NS_GNUC_WARN_UNUSED_RESULT __attribute__
> > ((__warn_unused_result__))
> > # define NS_GNUC_MAYALIAS __attribute__((__may_alias__))
> > #else
> > # define NS_GNUC_NONNULL(...)
> > # define NS_GNUC_WARN_UNUSED_RESULT
> > # define NS_GNUC_MAYALIAS
> > #endif
> >
> > Unfortunately, the
> >
> >    # define NS_GNUC_NONNULL(...)
> >
> > will not be accepted by the Microsoft compilers since it is
> > a varargs macro. They do not support varargs macros. Well.
> >
> > Now, idea is to just scrap the NS_GNUC_NONNULL entirely
> > when compiling with non-gcc compilers. Why? Because this
> > macro is really only used IF gcc, and, as far as I can
> > see it is used only here:
> >
> > #if __GNUC_PREREQ(2,7)
> > # define NS_GNUC_UNUSED __attribute__((__unused__))
> > # define NS_GNUC_NORETURN __attribute__((__noreturn__))
> > # define NS_GNUC_PRINTF(m, n) __attribute__((__format__ (__printf__,  m=
,
> > n))) NS_GNUC_NONNULL(m)
> > # define NS_GNUC_SCANF(m, n) __attribute__((__format__ (__scanf__, m,
> > n))) NS_GNUC_NONNULL(m)
> > #else
> > # define NS_GNUC_UNUSED
> > # define NS_GNUC_NORETURN
> > # define NS_GNUC_PRINTF(fmtarg, firstvararg)
> > # define NS_GNUC_SCANF(fmtarg, firstvararg)
> > #endif
> >
> > Are there any objections to remove the NS_GNUC_NONNULL?
> > Are there any better ideas?
> >
> > Cheers
> > Zoran
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

Re: [naviserver-devel] bad import

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

http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1230005&group_=
id=3D1&atid=3D200001


On 6/28/05, Vlad Seryakov <vl...@cr...> wrote:
> I managed to remove the wrong files but not sure if directory is there
>=20
> Vlad Seryakov wrote:
> > Stephen,
> >
> > I was importing new module and by mistake imported it into
> > naviserver/modules repository, second time i was able to put it into
> > modules/nsaccess.
> >
> > Can you ask admins to remove the wrong import?
> >
> > thanks
> >
>=20
> --
> Vlad Seryakov
> 571 262-8608 office
> vl...@cr...
> http://www.crystalballinc.com/vlad/
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>

[naviserver-devel] hey hey wiki

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

Hi NaviCoders,

I played a bit with the Wiki and started to add something to a Documentation 
section. Would be cool if you could just take a quick look the next days (no 
hurry) and rearrange/debug what you think fits better or is more logical.

Stephen, do you know how to make backups from that MySQL-stuff the easy way?


Bernd.

Re: [naviserver-devel] NS_GNUC_NONNULL on Windows?

[Ibrahim T. <it...@ar...>]

Hello everybody,

Please excuse my ignorance in the netickette and use of SF and 
the naviserver project - and please bear with me - I'm still 
learning.

To Zoran's request (motivated by myself):
Since NS_GNUC_NONNULL is not used anywhere else but in nscheck.h 
itself and only with GNUC, it suffices to remove it from the 
non-GNUC part to make it compilable for Windows.

Is it OK with you if I do so?

Greetings,
Ibrahim



Zoran Vasiljevic wrote:
> Hi frieds,
> 
> There seems to be a problem with NS_GNUC_NONNULL macro definition
> when compiling the code on Windows. This is how/where this beast
> is defined:
> 
> #if __GNUC_PREREQ(3,3)
> # define NS_GNUC_NONNULL(...) __attribute__((__nonnull__(__VA_ARGS__)))
> # define NS_GNUC_WARN_UNUSED_RESULT __attribute__ 
> ((__warn_unused_result__))
> # define NS_GNUC_MAYALIAS __attribute__((__may_alias__))
> #else
> # define NS_GNUC_NONNULL(...)
> # define NS_GNUC_WARN_UNUSED_RESULT
> # define NS_GNUC_MAYALIAS
> #endif
> 
> Unfortunately, the
> 
>    # define NS_GNUC_NONNULL(...)
> 
> will not be accepted by the Microsoft compilers since it is
> a varargs macro. They do not support varargs macros. Well.
> 
> Now, idea is to just scrap the NS_GNUC_NONNULL entirely
> when compiling with non-gcc compilers. Why? Because this
> macro is really only used IF gcc, and, as far as I can
> see it is used only here:
> 
> #if __GNUC_PREREQ(2,7)
> # define NS_GNUC_UNUSED __attribute__((__unused__))
> # define NS_GNUC_NORETURN __attribute__((__noreturn__))
> # define NS_GNUC_PRINTF(m, n) __attribute__((__format__ (__printf__,  m, 
> n))) NS_GNUC_NONNULL(m)
> # define NS_GNUC_SCANF(m, n) __attribute__((__format__ (__scanf__, m,  
> n))) NS_GNUC_NONNULL(m)
> #else
> # define NS_GNUC_UNUSED
> # define NS_GNUC_NORETURN
> # define NS_GNUC_PRINTF(fmtarg, firstvararg)
> # define NS_GNUC_SCANF(fmtarg, firstvararg)
> #endif
> 
> Are there any objections to remove the NS_GNUC_NONNULL?
> Are there any better ideas?
> 
> Cheers
> Zoran

[naviserver-devel] NS_GNUC_NONNULL on Windows?

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

Hi frieds,

There seems to be a problem with NS_GNUC_NONNULL macro definition
when compiling the code on Windows. This is how/where this beast
is defined:

#if __GNUC_PREREQ(3,3)
# define NS_GNUC_NONNULL(...) __attribute__((__nonnull__(__VA_ARGS__)))
# define NS_GNUC_WARN_UNUSED_RESULT __attribute__ 
((__warn_unused_result__))
# define NS_GNUC_MAYALIAS __attribute__((__may_alias__))
#else
# define NS_GNUC_NONNULL(...)
# define NS_GNUC_WARN_UNUSED_RESULT
# define NS_GNUC_MAYALIAS
#endif

Unfortunately, the

    # define NS_GNUC_NONNULL(...)

will not be accepted by the Microsoft compilers since it is
a varargs macro. They do not support varargs macros. Well.

Now, idea is to just scrap the NS_GNUC_NONNULL entirely
when compiling with non-gcc compilers. Why? Because this
macro is really only used IF gcc, and, as far as I can
see it is used only here:

#if __GNUC_PREREQ(2,7)
# define NS_GNUC_UNUSED __attribute__((__unused__))
# define NS_GNUC_NORETURN __attribute__((__noreturn__))
# define NS_GNUC_PRINTF(m, n) __attribute__((__format__ (__printf__,  
m, n))) NS_GNUC_NONNULL(m)
# define NS_GNUC_SCANF(m, n) __attribute__((__format__ (__scanf__, m,  
n))) NS_GNUC_NONNULL(m)
#else
# define NS_GNUC_UNUSED
# define NS_GNUC_NORETURN
# define NS_GNUC_PRINTF(fmtarg, firstvararg)
# define NS_GNUC_SCANF(fmtarg, firstvararg)
#endif

Are there any objections to remove the NS_GNUC_NONNULL?
Are there any better ideas?

Cheers
Zoran

Re: [naviserver-devel] Re: [naviserver-commits] naviserver/include ns.h,1.27,1.28

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

Am 29.06.2005 um 04:04 schrieb Stephen Deasey:
>
> The 'V' in Ns_ConnVSetHeaders() suggests it takes a va_list, as in
> Ns_DStringVPrintf() used in the implementation.
>
> Unfortunately, Ns_ConnPrintfHeader() already exists.  It prints
> directly to the output stream which looks pretty silly.  The function
> is unused.
>
> How about we rename your function Ns_ConnPrintfHeaders and drop
> Ns_ConnPrintfHeader?  Does anyone think that will be a problem?
>

No problem.