naviserver-devel — Developer discussion

Re: [naviserver-devel] How to listen on 2 ports?

[Jeff R. <dv...@di...>]

Vasiljevic Zoran wrote:
> He you socket/driver gurus out there!
> 
> What are my options if I want to have NS listen
> to more than one port?
> 
> We have the setup with just one virtual servers
> and listen on 0.0.0.0 address (all interfaces).
> What we would like to do is to listen on 1 more
> port but if possible from the same virtual server.
> I would not like to complicate things by introducing
> a second virtual server, it at all possible.
> 
> Ideas?

Naviserver may have changed enough underneath to be different here, but 
in aolserver, you can load the nssock module twice under different names 
and configure them separately.  Kind of like how the ssl driver is 
loaded separately from the plain socket driver.

I've used a config like this to accomplish it:

[ns/server/s/modules]
ns_param nssock nssock.so
ns_param nssock2 nssock.so

[ns/server/s/module/nssock]
ns_param Address bla.example.com
ns_param Port 80

[ns/server/s/module/nssock2[
ns_param Address bla.example.com
ns_param Port 8822

-J

Re: [naviserver-devel] How to listen on 2 ports?

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

Just load nssock second time with different name

ns_section ns/server/modules
ns_param nssock nssock.so
ns_param nssock2 nssock.so

ns_section ns/server/module/nssock
ns_param	port 90

ns_section ns/server/module/nssock2
ns_param	port 81

Vasiljevic Zoran wrote:
> He you socket/driver gurus out there!
> 
> What are my options if I want to have NS listen
> to more than one port?
> 
> We have the setup with just one virtual servers
> and listen on 0.0.0.0 address (all interfaces).
> What we would like to do is to listen on 1 more
> port but if possible from the same virtual server.
> I would not like to complicate things by introducing
> a second virtual server, it at all possible.
> 
> Ideas?
> 
> Zoran
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

[naviserver-devel] How to listen on 2 ports?

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

He you socket/driver gurus out there!

What are my options if I want to have NS listen
to more than one port?

We have the setup with just one virtual servers
and listen on 0.0.0.0 address (all interfaces).
What we would like to do is to listen on 1 more
port but if possible from the same virtual server.
I would not like to complicate things by introducing
a second virtual server, it at all possible.

Ideas?

Zoran

Re: [naviserver-devel] naviserver/nsd driver.c,1.119,1.120

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

I will try to take a look at this. With new API i could not figure out 
about pre-apending request data in Recv callback, so i had to come up 
with the solution which is almost the same as before.

It is just that now i need in my driver to keep track when actual binary 
data starts and i have to force driver to parse data that nobody need 
anyway, using more memory. Empty request now is supported, the work is 
done once and server can server requests without HTTP request at all.
Is this so bad?

Stephen Deasey wrote:
> On Wed, Oct 22, 2008 at 8:36 PM, Vlad Seryakov <vl...@cr...> wrote:
>>> static ssize_t
>>> Recv(Ns_Sock *sock, struct iovec *bufs, int nbufs, Ns_Time
>>> *timeoutPtr, int flags)
>>> {
>>>     static const char request[] = "GET /whateva HTTP/1.0\r\n\r\n";
>>>     size_t requestLen = sizeof(request);
>>>     socklen_t sockLen = sizeof(struct sockaddr_in);
>>>
>>>     memcpy(bufs->iov_base, request, requestLen);
>>>
>>>     return recvfrom(sock->sock,
>>>                     bufs->iov_base + requestLen,
>>>                     bufs->iov_len - requestLen,
>>>                     0, (struct sockaddr*) &sock->sa, &size);
>>> }
>>>
>>> (checking for buffer lengths skipped here)
>>>
>>>
>>> The advantage of doing it this way is that everything is much simpler
>>> from the driver threads point of view. It doesn't need to know
>>> anything special about non-standard protocols, and there isn't
>>> anything in the driver callback api that isn't also useful to the HTTP
>>> server.
>>
>> Arguable this is not very clear and simple, driver will have to hack
>> buffers and every request should pretend to be HTTP just so driver
>> thread would think that it serves only HTTP requests.
> 
> 
> It's clear and simple. It's maybe not very pretty :-)
> 
> 
>> If we have special codes and already have 3, does another one breaks
>> anythings if only one code makes overall process simpler not only in
>> driver thread but for drivers itself?
> 
> 
> It's a trade off.
> 
> Either non-standard drivers prepend their first read with 20 bytes in Recv().
> (~ two lines of code)
> 
> *OR*
> 
> You need to change all parts of the sever that expect an HTTP request
> structure to be available. AND you need to account for the fact that
> sometimes it gets created in the normal fashion, but other times it
> gets created later, or not at all.
> 
> 
> You've tried to ways to do this:
> 
> 
> 1) Exposing a new Ns_DriverSetRequest routine.
> 
> Here's what it looked like in nssyslogd:
> 
> http://naviserver.cvs.sourceforge.net/viewvc/naviserver/modules/nssyslogd/nssyslogd.c?revision=1.18&view=markup
> 
> NS_EXPORT int
> Ns_ModuleInit(char *server, char *module)
> {
>     ...
>     Ns_RegisterRequest(server, "SYSLOG",  "/", SyslogRequestProc,
> NULL, srvPtr, 0);
>     ...
> }
> 
> static NS_DRIVER_ACCEPT_STATUS
> Accept(Ns_Sock *sock, SOCKET listensock, struct sockaddr *sockaddrPtr,
> int *socklenPtr)
> {
>     sock->sock = listensock;
>     Ns_DriverSetRequest(sock, "SYSLOG / HTTP/1.0");
>     return NS_DRIVER_ACCEPT_DATA;
> }
> 
> 
> How is this functionally different to what I proposed (example in Recv above)?
> 
> 
> 2) Doing away with the need for a Ns_Request all together.
> 
> Which now looks like this:
> 
> http://naviserver.cvs.sourceforge.net/viewvc/naviserver/modules/nssyslogd/nssyslogd.c?revision=1.19&view=markup
> 
> NS_EXPORT int
> Ns_ModuleInit(char *server, char *module)
> {
>     ...
>     init.requestProc = Request;
>     ...
>     init.opts = NS_DRIVER_ASYNC | NS_DRIVER_NOPARSE;
>     ...
> }
> 
> static int
> Request(void *arg, Ns_Conn *conn)
> {
>     Ns_DString *dsPtr = Ns_ConnSockContent(conn);
>     SyslogRequest *req = SyslogRequestCreate(server, sockPtr->sock,
> dsPtr->string, dsPtr->length, &sa);
>     SyslogRequestProcess(req);
>     ...
> }
> 
> 
> The strategy here seems to be to completely ignore the standard
> request structure and do your own thing. There's nothing wrong with
> this in the abstract -- you're not actually using any of the HTTP
> stuff. However, the rest of the server fully expects the HTTP request
> to be present and filled in, and this is why you've had to touch
> dozens of files in dozens of places fixing up all code that might trip
> over a null request field. (And the public API has changed...)
> 
> 
> As far as I can see, neither method 1 or 2 achieves anything than
> passing "METHOD / HTTP/1.0\r\n\r\n" does, using considerably less
> code.
> 
> For example, In the snippet above, you can see the newly added
> Ns_ConnSockContent which returns a pointer to the read buffer (which
> is otherwise private). Ordinarily the buffer would contain the HTTP
> request line, any headers, then any body. You can get at the body with
> the existing Ns_ConnContent. So if you just return "SYSLOG /
> HTTP/1.0\r\n\r\n" and then your bytes in Recv(), the request would be
> constructed and then you could parse the protocol beginning in the
> body content.
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

Re: [naviserver-devel] naviserver/nsd driver.c,1.119,1.120

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

On Wed, Oct 22, 2008 at 8:36 PM, Vlad Seryakov <vl...@cr...> wrote:
>>
>> static ssize_t
>> Recv(Ns_Sock *sock, struct iovec *bufs, int nbufs, Ns_Time
>> *timeoutPtr, int flags)
>> {
>>     static const char request[] = "GET /whateva HTTP/1.0\r\n\r\n";
>>     size_t requestLen = sizeof(request);
>>     socklen_t sockLen = sizeof(struct sockaddr_in);
>>
>>     memcpy(bufs->iov_base, request, requestLen);
>>
>>     return recvfrom(sock->sock,
>>                     bufs->iov_base + requestLen,
>>                     bufs->iov_len - requestLen,
>>                     0, (struct sockaddr*) &sock->sa, &size);
>> }
>>
>> (checking for buffer lengths skipped here)
>>
>>
>> The advantage of doing it this way is that everything is much simpler
>> from the driver threads point of view. It doesn't need to know
>> anything special about non-standard protocols, and there isn't
>> anything in the driver callback api that isn't also useful to the HTTP
>> server.
>
>
> Arguable this is not very clear and simple, driver will have to hack
> buffers and every request should pretend to be HTTP just so driver
> thread would think that it serves only HTTP requests.


It's clear and simple. It's maybe not very pretty :-)


> If we have special codes and already have 3, does another one breaks
> anythings if only one code makes overall process simpler not only in
> driver thread but for drivers itself?


It's a trade off.

Either non-standard drivers prepend their first read with 20 bytes in Recv().
(~ two lines of code)

*OR*

You need to change all parts of the sever that expect an HTTP request
structure to be available. AND you need to account for the fact that
sometimes it gets created in the normal fashion, but other times it
gets created later, or not at all.


You've tried to ways to do this:


1) Exposing a new Ns_DriverSetRequest routine.

Here's what it looked like in nssyslogd:

http://naviserver.cvs.sourceforge.net/viewvc/naviserver/modules/nssyslogd/nssyslogd.c?revision=1.18&view=markup

NS_EXPORT int
Ns_ModuleInit(char *server, char *module)
{
    ...
    Ns_RegisterRequest(server, "SYSLOG",  "/", SyslogRequestProc,
NULL, srvPtr, 0);
    ...
}

static NS_DRIVER_ACCEPT_STATUS
Accept(Ns_Sock *sock, SOCKET listensock, struct sockaddr *sockaddrPtr,
int *socklenPtr)
{
    sock->sock = listensock;
    Ns_DriverSetRequest(sock, "SYSLOG / HTTP/1.0");
    return NS_DRIVER_ACCEPT_DATA;
}


How is this functionally different to what I proposed (example in Recv above)?


2) Doing away with the need for a Ns_Request all together.

Which now looks like this:

http://naviserver.cvs.sourceforge.net/viewvc/naviserver/modules/nssyslogd/nssyslogd.c?revision=1.19&view=markup

NS_EXPORT int
Ns_ModuleInit(char *server, char *module)
{
    ...
    init.requestProc = Request;
    ...
    init.opts = NS_DRIVER_ASYNC | NS_DRIVER_NOPARSE;
    ...
}

static int
Request(void *arg, Ns_Conn *conn)
{
    Ns_DString *dsPtr = Ns_ConnSockContent(conn);
    SyslogRequest *req = SyslogRequestCreate(server, sockPtr->sock,
dsPtr->string, dsPtr->length, &sa);
    SyslogRequestProcess(req);
    ...
}


The strategy here seems to be to completely ignore the standard
request structure and do your own thing. There's nothing wrong with
this in the abstract -- you're not actually using any of the HTTP
stuff. However, the rest of the server fully expects the HTTP request
to be present and filled in, and this is why you've had to touch
dozens of files in dozens of places fixing up all code that might trip
over a null request field. (And the public API has changed...)


As far as I can see, neither method 1 or 2 achieves anything than
passing "METHOD / HTTP/1.0\r\n\r\n" does, using considerably less
code.

For example, In the snippet above, you can see the newly added
Ns_ConnSockContent which returns a pointer to the read buffer (which
is otherwise private). Ordinarily the buffer would contain the HTTP
request line, any headers, then any body. You can get at the body with
the existing Ns_ConnContent. So if you just return "SYSLOG /
HTTP/1.0\r\n\r\n" and then your bytes in Recv(), the request would be
constructed and then you could parse the protocol beginning in the
body content.

Re: [naviserver-devel] modules/nsssl nsssl.c,1.6,1.7

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

The first argument is different, Ns_Sock vs SOCKET

Stephen Deasey wrote:
> On Wed, Oct 22, 2008 at 9:03 PM, Vlad Seryakov <vl...@cr...> wrote:
>> I tried to use Ns_SockSendBufs() but it sends data directly to socket
>> where i need to send via driver's send proc.
> 
> 
> Just pass your Send() proc directly, and delete SendBufs():
> 
>  static ssize_t
>  SendFile(Ns_Sock *sock, Ns_FileVec *bufs, int nbufs, Ns_Time
> *timeoutPtr, int flags)
>  {
> -    return Ns_SockSendFileBufsIndirect(sock->sock, bufs, nbufs,
> timeoutPtr, flags, SendBufs);
> +    return Ns_SockSendFileBufsIndirect(sock->sock, bufs, nbufs,
> timeoutPtr, flags, Send);
>  }
> 
> 
>> Why connPtr->nContentSent is not updated, all send called with conn
>> parameters should do this
> 
> 
> Yes, but Ns_ConnSend() is higher up the stack, so when sending data it
> looks something like this:
> 
> return.c: Ns_ConnReturnData
> connio.c: Ns_ConnWriteData
> connio.c: Ns_ConnWriteVData
> connio.c: Ns_ConnSend
> driver.c: NsDriverSend
> nsssl/nsssl.c: Send
> 
> 
> By the time your Send() is called we've already passed through
> Ns_ConnSend(). nContentSent will be updated as the stack unwinds.
> 
> If you call Ns_ConnSend() from within Send(), that's a loop...
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

Re: [naviserver-devel] modules/nsssl nsssl.c,1.6,1.7

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

On Wed, Oct 22, 2008 at 9:03 PM, Vlad Seryakov <vl...@cr...> wrote:
> I tried to use Ns_SockSendBufs() but it sends data directly to socket
> where i need to send via driver's send proc.


Just pass your Send() proc directly, and delete SendBufs():

 static ssize_t
 SendFile(Ns_Sock *sock, Ns_FileVec *bufs, int nbufs, Ns_Time
*timeoutPtr, int flags)
 {
-    return Ns_SockSendFileBufsIndirect(sock->sock, bufs, nbufs,
timeoutPtr, flags, SendBufs);
+    return Ns_SockSendFileBufsIndirect(sock->sock, bufs, nbufs,
timeoutPtr, flags, Send);
 }


> Why connPtr->nContentSent is not updated, all send called with conn
> parameters should do this


Yes, but Ns_ConnSend() is higher up the stack, so when sending data it
looks something like this:

return.c: Ns_ConnReturnData
connio.c: Ns_ConnWriteData
connio.c: Ns_ConnWriteVData
connio.c: Ns_ConnSend
driver.c: NsDriverSend
nsssl/nsssl.c: Send


By the time your Send() is called we've already passed through
Ns_ConnSend(). nContentSent will be updated as the stack unwinds.

If you call Ns_ConnSend() from within Send(), that's a loop...

Re: [naviserver-devel] modules/nsssl nsssl.c,1.6,1.7

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

I tried to use Ns_SockSendBufs() but it sends data directly to socket 
where i need to send via driver's send proc.

Why connPtr->nContentSent is not updated, all send called with conn 
parameters should do this

Stephen Deasey wrote:
>> Index: nsssl.c
>> ===================================================================
>> RCS file: /cvsroot/naviserver/modules/nsssl/nsssl.c,v
>> retrieving revision 1.6
>> retrieving revision 1.7
>> diff -C2 -d -r1.6 -r1.7
>> *** nsssl.c     22 Oct 2008 02:14:24 -0000      1.6
>> --- nsssl.c     22 Oct 2008 03:23:06 -0000      1.7
>> ***************
>> --- 432,447 ----
>>   */
>>
>> ! static int
>> ! SendBufs(SOCKET sock, struct iovec *bufs, int nbufs, Ns_Time *timeoutPtr, int flags)
>>  {
>> !     Ns_Conn *conn = Ns_GetConn();
>> !
>> !     return Ns_ConnSend(conn, bufs, nbufs);
>> ! }
>> !
> 
> 
> This should be Ns_SockSendBufs(), otherwise connPtr->nContentSent will
> be double counted and the driver thread may block.
> 
> Although in this case it should actually be Send(), which is your SSL
> specific implementation of Ns_SockSendBufs(). The way it is now static
> files may be sent in the clear :-/
> 
> 
> (Basically, you implement the SendFile() callback by calling
> Ns_SockSendFileIndirect(), which is the default library implementation
> which scrapes the bytes off disk, and pass it Send(), which is your
> implementation of writing to the network.  nssock is maybe a little
> confusing in that it doesn't actually do anything but call the default
> implementations, because it doesn't have to...)
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

Re: [naviserver-devel] modules/nsssl nsssl.c,1.6,1.7

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

> Index: nsssl.c
> ===================================================================
> RCS file: /cvsroot/naviserver/modules/nsssl/nsssl.c,v
> retrieving revision 1.6
> retrieving revision 1.7
> diff -C2 -d -r1.6 -r1.7
> *** nsssl.c     22 Oct 2008 02:14:24 -0000      1.6
> --- nsssl.c     22 Oct 2008 03:23:06 -0000      1.7
> ***************
> --- 432,447 ----
>   */
>
> ! static int
> ! SendBufs(SOCKET sock, struct iovec *bufs, int nbufs, Ns_Time *timeoutPtr, int flags)
>  {
> !     Ns_Conn *conn = Ns_GetConn();
> !
> !     return Ns_ConnSend(conn, bufs, nbufs);
> ! }
> !


This should be Ns_SockSendBufs(), otherwise connPtr->nContentSent will
be double counted and the driver thread may block.

Although in this case it should actually be Send(), which is your SSL
specific implementation of Ns_SockSendBufs(). The way it is now static
files may be sent in the clear :-/


(Basically, you implement the SendFile() callback by calling
Ns_SockSendFileIndirect(), which is the default library implementation
which scrapes the bytes off disk, and pass it Send(), which is your
implementation of writing to the network.  nssock is maybe a little
confusing in that it doesn't actually do anything but call the default
implementations, because it doesn't have to...)

Re: [naviserver-devel] modules/nsssl nsssl.c,1.6,1.7

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

> The check for (sslPtr == NULL) happens after it's already been used.


Oh, late night work :-((

Re: [naviserver-devel] modules/nsssl nsssl.c,1.6,1.7

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

On Wed, Oct 22, 2008 at 4:23 AM, Vlad Seryakov
<ser...@us...> wrote:
> Update of /cvsroot/naviserver/modules/nsssl
> In directory fdv4jf1.ch3.sourceforge.com:/tmp/cvs-serv22913/modules/nsssl
>
> Modified Files:
>        nsssl.c
> Log Message:
> new accept status, SSL driver works now
>
>
> Index: nsssl.c
> ===================================================================
> *** 286,298 ****
>
>          if (sslPtr == NULL) {
> !             sslPtr = SSL_new(drvPtr->ctx);
>              if (sslPtr == NULL) {
>                  Ns_Log(Error, "%d: SSL session init error for %s: [%s]", sock->sock, ns_inet_ntoa(sock->sa.sin_addr), strerror(errno));
>                  return NS_DRIVER_ACCEPT_ERROR;
>              }
>              sock->arg = sslPtr;
> !             SSL_set_fd(sslPtr, sock->sock);
> !             SSL_set_accept_state(sslPtr);
> !
>          }
>          return NS_DRIVER_ACCEPT_DATA;
> --- 293,306 ----
>
>          if (sslPtr == NULL) {
> !             sslPtr = ns_calloc(1, sizeof(SSLContext));
> !             sslPtr->ssl = SSL_new(drvPtr->ctx);
>              if (sslPtr == NULL) {
>                  Ns_Log(Error, "%d: SSL session init error for %s: [%s]", sock->sock, ns_inet_ntoa(sock->sa.sin_addr), strerror(errno));
> +                 ns_free(sslPtr);
>                  return NS_DRIVER_ACCEPT_ERROR;
>              }
>              sock->arg = sslPtr;
> !             SSL_set_fd(sslPtr->ssl, sock->sock);
> !             SSL_set_accept_state(sslPtr->ssl);
>          }
>          return NS_DRIVER_ACCEPT_DATA;
> ***************


The check for (sslPtr == NULL) happens after it's already been used.

Re: [naviserver-devel] naviserver/nsd driver.c,1.119,1.120

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

> 
> static ssize_t
> Recv(Ns_Sock *sock, struct iovec *bufs, int nbufs, Ns_Time
> *timeoutPtr, int flags)
> {
>     static const char request[] = "GET /whateva HTTP/1.0\r\n\r\n";
>     size_t requestLen = sizeof(request);
>     socklen_t sockLen = sizeof(struct sockaddr_in);
> 
>     memcpy(bufs->iov_base, request, requestLen);
> 
>     return recvfrom(sock->sock,
>                     bufs->iov_base + requestLen,
>                     bufs->iov_len - requestLen,
>                     0, (struct sockaddr*) &sock->sa, &size);
> }
> 
> (checking for buffer lengths skipped here)
> 
> 
> The advantage of doing it this way is that everything is much simpler
> from the driver threads point of view. It doesn't need to know
> anything special about non-standard protocols, and there isn't
> anything in the driver callback api that isn't also useful to the HTTP
> server.


Arguable this is not very clear and simple, driver will have to hack 
buffers and every request should pretend to be HTTP just so driver 
thread would think that it serves only HTTP requests.

If we have special codes and already have 3, does another one breaks 
anythings if only one code makes overall process simpler not only in 
driver thread but for drivers itself?

The only reason of new code because SOCK_READY does queue socket 
immediately but because request structure is not set, NsGetRequest will 
call SockRead/SockParse. Basically ACCEP_QEUEU code is the same as 
ACCEPT_DATA but it skips hacking HTTP request buffer and let the conn 
thread perform processing where ACCEPT_DATA assumes HTTP request and 
assumes HTTP flow to be performed.



> Also, this can't work:
> 
> nsd/driver.c:1515
> 
> status = DriverAccept(sockPtr);
> 
> if (status == NS_DRIVER_ACCEPT_ERROR) {
>     status = SOCK_ERROR;
>     ...
> 
> } else {
>     status = SOCK_MORE;
>     ...
> 
>     if (status == NS_DRIVER_ACCEPT_DATA) {
>         ...
>     } else if (status == NS_DRIVER_ACCEPT_QUEUE) {
>         ...
>     }
> }

Oops, my bad

Re: [naviserver-devel] naviserver/nsd driver.c,1.119,1.120

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

On Wed, Oct 22, 2008 at 4:23 AM, Vlad Seryakov
<ser...@us...> wrote:
> Update of /cvsroot/naviserver/naviserver/nsd
> In directory fdv4jf1.ch3.sourceforge.com:/tmp/cvs-serv22913/nsd
>
> Modified Files:
>        driver.c
> Log Message:
> new accept status, SSL driver works now
>
>
> Index: driver.c
> ===================================================================
> RCS file: /cvsroot/naviserver/naviserver/nsd/driver.c,v
> retrieving revision 1.119
> retrieving revision 1.120
> diff -C2 -d -r1.119 -r1.120
> *** driver.c    20 Oct 2008 00:06:54 -0000      1.119
> --- driver.c    22 Oct 2008 03:23:06 -0000      1.120
> ***************
> *** 787,791 ****
>   * Results:
>   *      _ACCEPT:       a socket was accepted, poll for data
> !  *      _ACCEPT_DATA:  a socket was accepted, data present
>   *      _ACCEPT_ERROR: no socket was accepted
>   *
> --- 787,793 ----
>   * Results:
>   *      _ACCEPT:       a socket was accepted, poll for data
> !  *      _ACCEPT_DATA:  a socket was accepted, data present, read immediately
> !  *                     if in async mode, defer reading to connection thread
> !  *      _ACCEPT_QUEUE: a socket was accepted, queue immediately
>   *      _ACCEPT_ERROR: no socket was accepted
>   *
> ***************
> *** 1523,1534 ****
>
>      } else {
>          drvPtr->queuesize++;
>
> -         /*
> -          * If there is already data present then read it without
> -          * polling if we're in async mode.
> -          */
> -
>          if (status == NS_DRIVER_ACCEPT_DATA) {
>              if (drvPtr->opts & NS_DRIVER_ASYNC) {
>                  status = SockRead(sockPtr, 0);
> --- 1525,1538 ----
>
>      } else {
> +         status = SOCK_MORE;
>          drvPtr->queuesize++;
>
>          if (status == NS_DRIVER_ACCEPT_DATA) {
> +
> +             /*
> +              * If there is already data present then read it without
> +              * polling if we're in async mode.
> +              */
> +
>              if (drvPtr->opts & NS_DRIVER_ASYNC) {
>                  status = SockRead(sockPtr, 0);
> ***************
> *** 1541,1553 ****
>
>                  /*
> !                  *  We need to call this to make sure socket has request structure allocated,
> !                  *  otherwise NsGetRequest will call SockRead which is not what this driver wants
>                   */
>
> -                 SockPrepare(sockPtr);
>                  status = SOCK_READY;
>              }
> !         } else {
> !             status = SOCK_MORE;
>          }
>      }
> --- 1545,1564 ----
>
>                  /*
> !                  * Queue this socket without reading, NsGetRequest in
> !                  * the connection thread will perform actual reading of the request
>                   */
>
>                  status = SOCK_READY;
>              }
> !         } else
> !         if (status == NS_DRIVER_ACCEPT_QUEUE) {
> !
> !             /*
> !              *  We need to call SockPrepare to make sure socket has request structure allocated,
> !              *  otherwise NsGetRequest will call SockRead which is not what this driver wants
> !              */
> !
> !             SockPrepare(sockPtr);
> !             status = SOCK_READY;
>          }
>      }


Why the new accept status: NS_DRIVER_ACCEPT_QUEUE ?

The idea we talked about with the driver callbacks was that a
non-standard driver could fake-up a request in it's read callback. So,
whereas at the mo you have something like this:

modules/nsudp/nsudp.c:

static NS_DRIVER_ACCEPT_STATUS
Accept(Ns_Sock *sock, SOCKET listensock, struct sockaddr *sockaddrPtr,
int *socklenPtr)
{
    sock->sock = listensock;
    return NS_DRIVER_ACCEPT_DATA;
}

static ssize_t
Recv(Ns_Sock *sock, struct iovec *bufs, int nbufs, Ns_Time
*timeoutPtr, int flags)
{
     socklen_t size = sizeof(struct sockaddr_in);

     return recvfrom(sock->sock, bufs->iov_base, bufs->iov_len, 0,
(struct sockaddr*)&sock->sa, &size);
}


You would instead do something like this:


static ssize_t
Recv(Ns_Sock *sock, struct iovec *bufs, int nbufs, Ns_Time
*timeoutPtr, int flags)
{
    static const char request[] = "GET /whateva HTTP/1.0\r\n\r\n";
    size_t requestLen = sizeof(request);
    socklen_t sockLen = sizeof(struct sockaddr_in);

    memcpy(bufs->iov_base, request, requestLen);

    return recvfrom(sock->sock,
                    bufs->iov_base + requestLen,
                    bufs->iov_len - requestLen,
                    0, (struct sockaddr*) &sock->sa, &size);
}

(checking for buffer lengths skipped here)


The advantage of doing it this way is that everything is much simpler
from the driver threads point of view. It doesn't need to know
anything special about non-standard protocols, and there isn't
anything in the driver callback api that isn't also useful to the HTTP
server.


Also, this can't work:

nsd/driver.c:1515

status = DriverAccept(sockPtr);

if (status == NS_DRIVER_ACCEPT_ERROR) {
    status = SOCK_ERROR;
    ...

} else {
    status = SOCK_MORE;
    ...

    if (status == NS_DRIVER_ACCEPT_DATA) {
        ...
    } else if (status == NS_DRIVER_ACCEPT_QUEUE) {
        ...
    }
}

Re: [naviserver-devel] naviserver ChangeLog,1.820,1.821

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

Right

Stephen Deasey wrote:
> On Wed, Oct 22, 2008 at 3:14 AM, Vlad Seryakov
> <ser...@us...> wrote:
>> Update of /cvsroot/naviserver/naviserver
>> In directory fdv4jf1.ch3.sourceforge.com:/tmp/cvs-serv17830
>>
>> Modified Files:
>>        ChangeLog
>> Log Message:
>> nsssl module ported, sock context and driver context exposed
>>
>>
>> Index: ChangeLog
>> ===================================================================
>> RCS file: /cvsroot/naviserver/naviserver/ChangeLog,v
>> retrieving revision 1.820
>> retrieving revision 1.821
>> diff -C2 -d -r1.820 -r1.821
>> *** ChangeLog   21 Oct 2008 21:46:36 -0000      1.820
>> --- ChangeLog   22 Oct 2008 02:14:23 -0000      1.821
>> ***************
>> *** 13,16 ****
>> --- 13,24 ----
>>          modules/nstftpd: ported to new driver API
>>
>> +         modules/nsssl: Ported to new API
>> +
>> +         nsd/conn.c: Added new Ns_ConnSockContext function which returns sock->arg,
>> +         socket-wide context
>> +
>> +         Ns_ConnDriverContext will now return connPtr->drvPtr->arg, this is driver-wide
>> +         context.
>> +
> 
> 
> These structure members are already public, so Ns_ConnSockContext()
> and Ns_ConnDriverContext() are not needed:
> 
> include/ns.h:
> 
> typedef struct Ns_Sock {
>     Ns_Driver          *driver;
>     SOCKET              sock;           /* Connection socket */
>     struct sockaddr_in  sa;             /* Actual peer address */
>     void               *arg;            /* Driver context. */
> } Ns_Sock;
> 
> typedef struct Ns_Driver {
>     void    *arg;           /* Driver callback data. */
>    ...
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

Re: [naviserver-devel] naviserver ChangeLog,1.820,1.821

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

On Wed, Oct 22, 2008 at 3:14 AM, Vlad Seryakov
<ser...@us...> wrote:
> Update of /cvsroot/naviserver/naviserver
> In directory fdv4jf1.ch3.sourceforge.com:/tmp/cvs-serv17830
>
> Modified Files:
>        ChangeLog
> Log Message:
> nsssl module ported, sock context and driver context exposed
>
>
> Index: ChangeLog
> ===================================================================
> RCS file: /cvsroot/naviserver/naviserver/ChangeLog,v
> retrieving revision 1.820
> retrieving revision 1.821
> diff -C2 -d -r1.820 -r1.821
> *** ChangeLog   21 Oct 2008 21:46:36 -0000      1.820
> --- ChangeLog   22 Oct 2008 02:14:23 -0000      1.821
> ***************
> *** 13,16 ****
> --- 13,24 ----
>          modules/nstftpd: ported to new driver API
>
> +         modules/nsssl: Ported to new API
> +
> +         nsd/conn.c: Added new Ns_ConnSockContext function which returns sock->arg,
> +         socket-wide context
> +
> +         Ns_ConnDriverContext will now return connPtr->drvPtr->arg, this is driver-wide
> +         context.
> +


These structure members are already public, so Ns_ConnSockContext()
and Ns_ConnDriverContext() are not needed:

include/ns.h:

typedef struct Ns_Sock {
    Ns_Driver          *driver;
    SOCKET              sock;           /* Connection socket */
    struct sockaddr_in  sa;             /* Actual peer address */
    void               *arg;            /* Driver context. */
} Ns_Sock;

typedef struct Ns_Driver {
    void    *arg;           /* Driver callback data. */
   ...

Re: [naviserver-devel] naviserver/include nsthread.h,1.42,1.43

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

I think we can just remove the O_LARGEFILE usage from log.c (only
place it's used).

_FILE_OFFSET_BITS handles this now.


On Sun, Oct 5, 2008 at 6:03 PM, Vlad Seryakov
<ser...@us...> wrote:
> Update of /cvsroot/naviserver/naviserver/include
> In directory fdv4jf1.ch3.sourceforge.com:/tmp/cvs-serv21771/include
>
> Modified Files:
>        nsthread.h
> Log Message:
> OS X does not have O_LARGEFILE
>
>
> Index: nsthread.h
> ===================================================================
> RCS file: /cvsroot/naviserver/naviserver/include/nsthread.h,v
> retrieving revision 1.42
> retrieving revision 1.43
> diff -C2 -d -r1.42 -r1.43
> *** nsthread.h  2 Oct 2008 01:36:18 -0000       1.42
> --- nsthread.h  5 Oct 2008 17:03:49 -0000       1.43
> ***************
> *** 246,249 ****
> --- 246,253 ----
>  #endif
>
> + #ifdef __APPLE__
> + #define O_LARGEFILE                 0
> + #endif
> +
>  #define O_TEXT                      0
>  #define O_BINARY                    0
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> naviserver-commits mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-commits
>

Re: [naviserver-devel] naviserver ChangeLog,1.787,1.788

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

You can go ahead and patch CVS directly, i agree with the approach and 
all other modules i will port one by one. Not all i use now, mostly UDP 
and Syslog, so it is not a big deal.

I though as well about reading in acceptProc and queue, it just needs 
public Queue function and the rest can be done inside each module.

Stephen Deasey wrote:
> On Fri, Sep 12, 2008 at 3:08 AM, Vlad Seryakov <vl...@cr...> wrote:
>> I agree about making modules take care as much as possible.
>>
>> But here are the questions i need to resolve:
>>
>> - init, socket needs to be created, UDP or TCP or Unix, so driver needs
>> initProc
>>
>> - for module like UDP, driver needs to know not to accept or we need
>> another proc called acceptProc, default will be using accept and treat
>> socket as TCP but drier can ovwerwrite with its own
>>
>> - queuing, at some point, after accept or later driver need to queue
>> socket. The reason behind QUEUE_ON_ACCEPT to take care basic stuff
>> without writing same code for creating separate thread for slitening and
>> accepting sockets. SMTP is a good example in nssmtp.
>> QUEUE_ONREAD is usefull in case of UDP sockets, after reading UDP packet
>> call registered proc
>>
>> So, i need to resolve these issues and i would like to move as much as
>> possible into drivers.
>>
>> Any suggestions?
> 
> 
> Yeah, create listen and accept callbacks.
> 
> I think TCP drivers should work fine -- I did that ages ago with the
> example pop3 driver.
> 
> The UDP though...  Maybe they should just read the packet in the
> accept callback, stash it, fake-up the HTTP request line in the Read
> callback, and the conn thread can then access the stashed packet
> directly.
> 
> I'll have another go at it later, but here's some cleaned and split
> patches anyway, if you get a chance.
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

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

Re: [naviserver-devel] naviserver ChangeLog,1.787,1.788

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

On Fri, Sep 12, 2008 at 3:08 AM, Vlad Seryakov <vl...@cr...> wrote:
> I agree about making modules take care as much as possible.
>
> But here are the questions i need to resolve:
>
> - init, socket needs to be created, UDP or TCP or Unix, so driver needs
> initProc
>
> - for module like UDP, driver needs to know not to accept or we need
> another proc called acceptProc, default will be using accept and treat
> socket as TCP but drier can ovwerwrite with its own
>
> - queuing, at some point, after accept or later driver need to queue
> socket. The reason behind QUEUE_ON_ACCEPT to take care basic stuff
> without writing same code for creating separate thread for slitening and
> accepting sockets. SMTP is a good example in nssmtp.
> QUEUE_ONREAD is usefull in case of UDP sockets, after reading UDP packet
> call registered proc
>
> So, i need to resolve these issues and i would like to move as much as
> possible into drivers.
>
> Any suggestions?


Yeah, create listen and accept callbacks.

I think TCP drivers should work fine -- I did that ages ago with the
example pop3 driver.

The UDP though...  Maybe they should just read the packet in the
accept callback, stash it, fake-up the HTTP request line in the Read
callback, and the conn thread can then access the stashed packet
directly.

I'll have another go at it later, but here's some cleaned and split
patches anyway, if you get a chance.

Re: [naviserver-devel] naviserver ChangeLog,1.787,1.788

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

I agree about making modules take care as much as possible.

But here are the questions i need to resolve:

- init, socket needs to be created, UDP or TCP or Unix, so driver needs 
initProc

- for module like UDP, driver needs to know not to accept or we need 
another proc called acceptProc, default will be using accept and treat 
socket as TCP but drier can ovwerwrite with its own

- queuing, at some point, after accept or later driver need to queue 
socket. The reason behind QUEUE_ON_ACCEPT to take care basic stuff 
without writing same code for creating separate thread for slitening and 
accepting sockets. SMTP is a good example in nssmtp.
QUEUE_ONREAD is usefull in case of UDP sockets, after reading UDP packet 
call registered proc

So, i need to resolve these issues and i would like to move as much as 
possible into drivers.

Any suggestions?

Stephen Deasey wrote:
> On Fri, Aug 29, 2008 at 2:12 AM, Vlad Seryakov <vl...@cr...> wrote:
>> And sent email without finishing the thought :-))
>>
>> Maybe parsing for range should done early enough and saved in the
>> request, so whoever then will be sending data will use it.
>>
>> Just a thought from east coast :-))
>>
> 
> 
> Here's a couple of patches as a follow on to recent checkins to cvs:
> 
>   registerdriver.diff
>   setlength.diff
>   range-sendfile.diff
> 
> The first changes the prototype of the Driver callback. Actually it
> removes it and adds a callback for each function: send, receive, keep,
> close, and adds a new one: sendfile.
> 
> The second is just a clarification on the handling of length headers,
> but it's needed for the third.
> 
> The third changes the range code to use the new sendfile support.  I
> changed it round so that instead of saying SendRange you say
> ParseRange. You pass it an array of Ns_FileVec's, it looks at the
> headers and it fills it in for you.  I haven't tried, but this should
> allow you to allocate an array of Ns_FileVec's and associate it with
> the socket for the writer thread. We might have to also fixup the
> timeout handling in the Ns_Sock* stuff -- It seems to always want to
> do a poll timeout the way it's currently written.
> 
> 
> I didn't want to check any of this in because the API change will
> break half a dozen of your driver modules. So whenever you get a
> chance (no rush) try out the registerdriver.diff patch and see if you
> can get your modules working with it.
> 
> I did notice a couple of odd things. NsDriverClose() get called twice
> for each socket. Not sure why, but I don't think it should. I've
> changed the semantics: it used to be "Notify the driver that we are
> going to close", now we delegate the close to the driver, which for
> nssock is simply ns_sockclose().  The advantage is that for other
> modules, like your nsudp, you should be able to handle whatever needs
> to be handled. For example nsudp wants to keep the socket open.
> Previously this was handled with special logic in the driver thread
> checking for if UDP, else !UDP.  I think this complication is where
> the DriverClose x2 bug crept in.
> 
> I haven't thoroughly checked it, but I'm 95% confident that you could
> handle all the special cases for the current alternative drivers more
> cleanly by delegating to the driver callbacks and removing all the
> special logic to do with NS_DRIVER_* (UDP, UNIX, QUEUE_ONACCEPT,
> QUEUE_ONREAD).  Have another look and see what you think.
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

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

Re: [naviserver-devel] naviserver ChangeLog,1.787,1.788

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

On Thu, Sep 11, 2008 at 10:53 PM, Vlad Seryakov <vl...@cr...> wrote:
> will do, it may take a while
>

no problem

Re: [naviserver-devel] naviserver ChangeLog,1.787,1.788

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

will do, it may take a while

Stephen Deasey wrote:
> On Fri, Aug 29, 2008 at 2:12 AM, Vlad Seryakov <vl...@cr...> wrote:
>> And sent email without finishing the thought :-))
>>
>> Maybe parsing for range should done early enough and saved in the
>> request, so whoever then will be sending data will use it.
>>
>> Just a thought from east coast :-))
>>
> 
> 
> Here's a couple of patches as a follow on to recent checkins to cvs:
> 
>   registerdriver.diff
>   setlength.diff
>   range-sendfile.diff
> 
> The first changes the prototype of the Driver callback. Actually it
> removes it and adds a callback for each function: send, receive, keep,
> close, and adds a new one: sendfile.
> 
> The second is just a clarification on the handling of length headers,
> but it's needed for the third.
> 
> The third changes the range code to use the new sendfile support.  I
> changed it round so that instead of saying SendRange you say
> ParseRange. You pass it an array of Ns_FileVec's, it looks at the
> headers and it fills it in for you.  I haven't tried, but this should
> allow you to allocate an array of Ns_FileVec's and associate it with
> the socket for the writer thread. We might have to also fixup the
> timeout handling in the Ns_Sock* stuff -- It seems to always want to
> do a poll timeout the way it's currently written.
> 
> 
> I didn't want to check any of this in because the API change will
> break half a dozen of your driver modules. So whenever you get a
> chance (no rush) try out the registerdriver.diff patch and see if you
> can get your modules working with it.
> 
> I did notice a couple of odd things. NsDriverClose() get called twice
> for each socket. Not sure why, but I don't think it should. I've
> changed the semantics: it used to be "Notify the driver that we are
> going to close", now we delegate the close to the driver, which for
> nssock is simply ns_sockclose().  The advantage is that for other
> modules, like your nsudp, you should be able to handle whatever needs
> to be handled. For example nsudp wants to keep the socket open.
> Previously this was handled with special logic in the driver thread
> checking for if UDP, else !UDP.  I think this complication is where
> the DriverClose x2 bug crept in.
> 
> I haven't thoroughly checked it, but I'm 95% confident that you could
> handle all the special cases for the current alternative drivers more
> cleanly by delegating to the driver callbacks and removing all the
> special logic to do with NS_DRIVER_* (UDP, UNIX, QUEUE_ONACCEPT,
> QUEUE_ONREAD).  Have another look and see what you think.
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Re: [naviserver-devel] naviserver ChangeLog,1.787,1.788

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

On Fri, Aug 29, 2008 at 2:12 AM, Vlad Seryakov <vl...@cr...> wrote:
> And sent email without finishing the thought :-))
>
> Maybe parsing for range should done early enough and saved in the
> request, so whoever then will be sending data will use it.
>
> Just a thought from east coast :-))
>


Here's a couple of patches as a follow on to recent checkins to cvs:

  registerdriver.diff
  setlength.diff
  range-sendfile.diff

The first changes the prototype of the Driver callback. Actually it
removes it and adds a callback for each function: send, receive, keep,
close, and adds a new one: sendfile.

The second is just a clarification on the handling of length headers,
but it's needed for the third.

The third changes the range code to use the new sendfile support.  I
changed it round so that instead of saying SendRange you say
ParseRange. You pass it an array of Ns_FileVec's, it looks at the
headers and it fills it in for you.  I haven't tried, but this should
allow you to allocate an array of Ns_FileVec's and associate it with
the socket for the writer thread. We might have to also fixup the
timeout handling in the Ns_Sock* stuff -- It seems to always want to
do a poll timeout the way it's currently written.


I didn't want to check any of this in because the API change will
break half a dozen of your driver modules. So whenever you get a
chance (no rush) try out the registerdriver.diff patch and see if you
can get your modules working with it.

I did notice a couple of odd things. NsDriverClose() get called twice
for each socket. Not sure why, but I don't think it should. I've
changed the semantics: it used to be "Notify the driver that we are
going to close", now we delegate the close to the driver, which for
nssock is simply ns_sockclose().  The advantage is that for other
modules, like your nsudp, you should be able to handle whatever needs
to be handled. For example nsudp wants to keep the socket open.
Previously this was handled with special logic in the driver thread
checking for if UDP, else !UDP.  I think this complication is where
the DriverClose x2 bug crept in.

I haven't thoroughly checked it, but I'm 95% confident that you could
handle all the special cases for the current alternative drivers more
cleanly by delegating to the driver callbacks and removing all the
special logic to do with NS_DRIVER_* (UDP, UNIX, QUEUE_ONACCEPT,
QUEUE_ONREAD).  Have another look and see what you think.

Re: [naviserver-devel] 2006-06-24 -> FCGI

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

On 10.09.2008, at 17:22, Vlad Seryakov wrote:

> As usual, to start is the hardest thing

Effectively, mod_fcgi can be used as start
but (my gut feeling) thanks to our cleaner and
more advanced C-API, it could be much less work. 

Re: [naviserver-devel] 2006-06-24 -> FCGI

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

On 10.09.2008, at 17:22, Vlad Seryakov wrote:

> As usual, to start is the hardest thing

Indeed!

Re: [naviserver-devel] 2006-06-24 -> FCGI

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

I would help in co-developing and testing it but right now my head is 
too busy with other project so it is hard to start this new module.
As usual, to start is the hardest thing

Bernd Eidenschink wrote:
>> Yes, that's why i thought about developing fcgi module for ns, just to
>> make an option for Rails and other frameworks to run on naviserver. It
>> could work like for nginx, but could not, still an option is an option.
> 
> True. These frameworks offer so much so nicely out of the box one would never 
> want to re-invent in ADP/Tcl.
> 
> And on the other hand they need a real webserver doing all the return huge 
> files, return lots of cached small files etc. stuff.
> 
> Bernd.
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>