Re: [AOLSERVER] Win mmap()
This one brings the question: why not go and abstract other #ifdef's arround the code? Perhaps adding a compat or win/unix or such directory with platform-specific stuff a'la Tcl? I'm not sure how bit that effort is, but is worth examining since it will ease the server maintenance greatly. AOL is not going to do this for us, we have to make sure it is done by the community. This will ease everybody's life. To maximize portability, AOLserver could probably use the Tcl API even more than it does now, and in a few cases modules aren't taking advantage of the portability abstractions we already have, for example, in the latest nsopenssl sources, struct timeval should get changed to Ns_Time. We may want to expose some new wrapper functions in the API for use by module authors, e.g. Ns_MemMap for mmap functionality. There are currently only a few platform specific files in the tree, if we were going to add more it might be worth putting them into separate dirs the way Tcl does, but I don't think that would be very helpful right now. I've started work on a nightly Win32 build, which should hopefully help us catch portability problems as soon as they are committed. I also need to make a list of all of the Win32 and general enhancements in our local tree so that we can discuss moving them into the core. Jamie -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Win mmap()
[EMAIL PROTECTED] wrote: This one brings the question: why not go and abstract other #ifdef's arround the code? Perhaps adding a compat or win/unix or such directory with platform-specific stuff a'la Tcl? I'm not sure how bit that effort is, but is worth examining since it will ease the server maintenance greatly. AOL is not going to do this for us, we have to make sure it is done by the community. This will ease everybody's life. To maximize portability, AOLserver could probably use the Tcl API even more than it does now, and in a few cases modules aren't taking advantage of the portability abstractions we already have, for example, in the latest nsopenssl sources, struct timeval should get changed to Ns_Time. We may want to expose some new wrapper functions in the API for use by module authors, e.g. Ns_MemMap for mmap functionality. Would it make sense to look changing some of the core Ns_() API's to instead be written on top of existing abstraction layers such as Apache APR or Netscape NSPR? http://apr.apache.org/ http://www.mozilla.org/projects/nspr/ Downside is that it could add some complexity and would definitly add external dependencies. Upside is that it could open the door to other things. Using NSPR would enable us to use NSS. http://www.mozilla.org/projects/security/pki/nss/ If memory serves, there is a version of AOLserver floating around that was built on top of NSPR/NSS. I don't think much code had to be changed, and the performance hit wasn't noticeable. There are currently only a few platform specific files in the tree, if we were going to add more it might be worth putting them into separate dirs the way Tcl does, but I don't think that would be very helpful right now. I've started work on a nightly Win32 build, which should hopefully help us catch portability problems as soon as they are committed. I also need to make a list of all of the Win32 and general enhancements in our local tree so that we can discuss moving them into the core. Jamie -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Win mmap()
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: This one brings the question: why not go and abstract other #ifdef's arround the code? Perhaps adding a compat or win/unix or such directory with platform-specific stuff a'la Tcl? I'm not sure how bit that effort is, but is worth examining since it will ease the server maintenance greatly. AOL is not going to do this for us, we have to make sure it is done by the community. This will ease everybody's life. To maximize portability, AOLserver could probably use the Tcl API even more than it does now, and in a few cases modules aren't taking advantage of the portability abstractions we already have, for example, in the latest nsopenssl sources, struct timeval should get changed to Ns_Time. We may want to expose some new wrapper functions in the API for use by module authors, e.g. Ns_MemMap for mmap functionality. Would it make sense to look changing some of the core Ns_() API's to instead be written on top of existing abstraction layers such as Apache APR or Netscape NSPR? http://apr.apache.org/ http://www.mozilla.org/projects/nspr/ Downside is that it could add some complexity and would definitly add external dependencies. Upside is that it could open the door to other things. Using NSPR would enable us to use NSS. http://www.mozilla.org/projects/security/pki/nss/ If memory serves, there is a version of AOLserver floating around that was built on top of NSPR/NSS. I don't think much code had to be changed, and the performance hit wasn't noticeable. Looks like this is already possible today. There's an nsnss module available from the AOLserver sourceforge CVS repository - $TOP/nsnss. Pretty cool! There are currently only a few platform specific files in the tree, if we were going to add more it might be worth putting them into separate dirs the way Tcl does, but I don't think that would be very helpful right now. I've started work on a nightly Win32 build, which should hopefully help us catch portability problems as soon as they are committed. I also need to make a list of all of the Win32 and general enhancements in our local tree so that we can discuss moving them into the core. Jamie -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] Win mmap()
On Tuesday 17 August 2004 20:17, you wrote: To maximize portability, AOLserver could probably use the Tcl API even more than it does now, and in a few cases modules aren't taking advantage of the portability abstractions we already have, for example, in the latest nsopenssl sources, struct timeval should get changed to Ns_Time. We may want to expose some new wrapper functions in the API for use by module authors, e.g. Ns_MemMap for mmap functionality. Good. This is the obvious one. We may address one after another when we stumble against one of those on the road. There are currently only a few platform specific files in the tree, if we were going to add more it might be worth putting them into separate dirs the way Tcl does, but I don't think that would be very helpful right now. I've started work on a nightly Win32 build, which should hopefully help us catch portability problems as soon as they are committed. I also need to make a list of all of the Win32 and general enhancements in our local tree so that we can discuss moving them into the core. Great. Lets review them then. I have a collegue here who is looking after the Win port locally. I will include him so we can move forward. Zoran -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
