Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
On 2001.12.19, Rusty Brooks [EMAIL PROTECTED] wrote: Internet explorer does not, from my examination of the available literature, support server push, at least not in any way I could get it to work. You're right. That sucks. However, I'm sure with IE you could trick out some kind of server push with a small ActiveX control. *chuckle* -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
On Thu, 20 Dec 2001, Dossy wrote: You're right. That sucks. However, I'm sure with IE you could trick out some kind of server push with a small ActiveX control. ...or a Java applet, or a Tclet, or some other _non-HTTP_ solution. That's what I was saying -- HTTP is the wrong protocol for this. Doesn't mean HTTP isn't a good protocol, it just means it wasn't designed for this type of dialog control. Pete.
Re: [AOLSERVER] GCC compilation of AOLserver 4.x fails due to -rpath
You're right -- RPATH isn't used anywhere. RFLAG is used eventually in include/Makefile.library, which becomes included in nsd/Makefile: $(LDSO) -o $(LIB) $(OBJS) $(LIBS) $(RFLAG) $(AOLSERVER)/lib This should be changed to: $(LDSO) -o $(LIB) $(OBJS) $(LIBS) $(RPATH) Note that I removed the $(AOLSERVER)/lib as it's part of RPATH. If RPATH is defined as , then having $(AOLSERVER)/lib at the end of the LDSO line will cause an error. Strangely, the Solaris build has this: RFLAG = -R RPATH += -Wl,$(RFLAG),/usr/lib/lwp Which makes RPATH for Solaris end up looking like: RPATH = -Wl,-rpath,$(AOLSERVER)/lib -Wl,-R,/usr/lib/lwp I'm not sure whether this was the intention. Another side-effect as that $(AOLSERVER)/lib must exist as a directory before the compile will work, but $(AOLSERVER)/lib isn't created until after you run make install. I'll commit the above mentioned changes to CVS later today. thanks, /s. Scott, Notice what you included in your original post: gcc -shared -nostartfiles -o libnspd.so listen.o log.omain.o ../nsext/nsextmsg.o -L../tcl8.3.4/unix -ltcl8.3g -lm -ldl -lpthread -rpath ../../install/aolserver/lib Note that it's just got -rpath and not -Wl,-rpath,$(AOLSERVER)/lib there. Which means, the build rule is using $(RFLAG) instead of $(RPATH). Leave RFLAG and RPATH as they are, and fix the build rule by replacing $(RFLAG) with $(RPATH) where appropriate. I haven't checked out of CVS lately, so I can't tell you specifically where appropriate is ... but if you can't find it, I'll do a cvs update and look myself. -- Dossy On 2001.12.19, Scott Goodwin [EMAIL PROTECTED] wrote: Problem solved. It didn't quite work with what you sent, but it led me to this, which did work: RFLAG = -Xlinker -rpath RPATH = $(RFLAG) $(AOLSERVER)/lib Note that -Wl is *supposed* to pass the comma-separated list to the linker, removing the commas in the process. This doesn't appear to work as advertised: RPATH = -Wl,$(RFLAG),$(AOLSERVER)/lib Now I'm pondering whether to commit the changes to sourceforge; I'm not comfortable that this solution fixes my problem *AND* doesn't break the compile on other systems and platforms. thanks, Pete, /s. Try changing the definitions to this: RFLAG = -Xlinker -rpath RPATH = -Xlinker -Wl,$(RFLAG),$(AOLSERVER)/lib -Xlinker is a gcc switch to pass arguments to the linker. The man page says that if the linker argument takes a parameter, then you must use -Xlinker twice -- once for the argument and once for the parameter. It specifically says that quoting the argument and parameter won't work. I think AOLserver used to invoke ld directly, in which case the -rpath would have worked, but on some platforms or versions of gcc, particularly with shared libraries, you just don't get the same output from ld as you do from gcc, no matter what arguments you throw at it. It's probably fixable, but it's just so much easier to use gcc for everything. Pete. -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
[AOLSERVER] [ aolserver-Feature Requests-432532 ] Better version numbering in source code
Feature Requests item #432532, was opened at 2001-06-12 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=353152aid=432532group_id=3152 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Scott Goodwin (scottg) Assigned to: Nobody/Anonymous (nobody) Summary: Better version numbering in source code Initial Comment: I'd like to see better version numbering in the AOLserver source code to make it easier for modules to conditionally compile chunks based on the server's version release. Right now, NSD_VERSION is defined in nsd/nsd.h like this: #define NSD_VERSION 3.4 However, this is a pain to use for #if preprocessing statements. Case in point. I need the nsopenssl module to be able to determine whether the version number is greater than 3.4 (or less than 4). It's not easy to do this when NSD_VERSION is set to 4.0b or 3.4. I cannot do this, for example: #if NSD_VERSION 3.4 because the preprocessor thinks 3.4 is a string, not a number. OpenSSL version numbers are used like this: #if SSLEAY_VERSION_NUMBER = 0x0090581fL ... stuff ... #else ... other stuff ... #endif I propose we do something a little less cryptic: 1. create an include/version.h file 2. in that file, place the following: #define AOLSERVER_MAJOR_VERSION 3 #define AOLSERVER_MINOR_VERSION 4 #define AOLSERVER_RELEASE_STATUS beta This would allow me to do the following: #if AOLSERVER_MAJOR_RELEASE 4 ... compile for aolserver 3.x ... #else ... compile for aolserver 4.x ... #endif It would also allow me to put in code for alpha and beta releases of the server that won't affect anyone who is compiling against a released version. It's too late to do this for the 3.x series, but if we start out like this with version 4.x, I can do this: #ifndef AOLSERVER_MAJOR_RELEASE ... assume it's 3.x ... #else ... assume it's 4.x ... #endif I have commit access to the repository to do this, but I want others to review before I make this happen. Maybe there is a better way to do this without altering the source. thanks, /s. -- Comment By: Scott Goodwin (scottg) Date: 2001-06-12 13:33 Message: Logged In: YES user_id=37651 Minor typos I just noticed: Everywhere you see AOLSERVER_MAJOR_RELEASE, please substitute AOLSERVER_MAJOR_VERSION. /s. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=353152aid=432532group_id=3152
[AOLSERVER] [ aolserver-Feature Requests-432532 ] Better version numbering in source code
Feature Requests item #432532, was opened at 2001-06-12 13:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=353152aid=432532group_id=3152 Category: None Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Scott Goodwin (scottg) Assigned to: Nobody/Anonymous (nobody) Summary: Better version numbering in source code Initial Comment: I'd like to see better version numbering in the AOLserver source code to make it easier for modules to conditionally compile chunks based on the server's version release. Right now, NSD_VERSION is defined in nsd/nsd.h like this: #define NSD_VERSION 3.4 However, this is a pain to use for #if preprocessing statements. Case in point. I need the nsopenssl module to be able to determine whether the version number is greater than 3.4 (or less than 4). It's not easy to do this when NSD_VERSION is set to 4.0b or 3.4. I cannot do this, for example: #if NSD_VERSION 3.4 because the preprocessor thinks 3.4 is a string, not a number. OpenSSL version numbers are used like this: #if SSLEAY_VERSION_NUMBER = 0x0090581fL ... stuff ... #else ... other stuff ... #endif I propose we do something a little less cryptic: 1. create an include/version.h file 2. in that file, place the following: #define AOLSERVER_MAJOR_VERSION 3 #define AOLSERVER_MINOR_VERSION 4 #define AOLSERVER_RELEASE_STATUS beta This would allow me to do the following: #if AOLSERVER_MAJOR_RELEASE 4 ... compile for aolserver 3.x ... #else ... compile for aolserver 4.x ... #endif It would also allow me to put in code for alpha and beta releases of the server that won't affect anyone who is compiling against a released version. It's too late to do this for the 3.x series, but if we start out like this with version 4.x, I can do this: #ifndef AOLSERVER_MAJOR_RELEASE ... assume it's 3.x ... #else ... assume it's 4.x ... #endif I have commit access to the repository to do this, but I want others to review before I make this happen. Maybe there is a better way to do this without altering the source. thanks, /s. -- Comment By: Scott Goodwin (scottg) Date: 2001-06-12 13:33 Message: Logged In: YES user_id=37651 Minor typos I just noticed: Everywhere you see AOLSERVER_MAJOR_RELEASE, please substitute AOLSERVER_MAJOR_VERSION. /s. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=353152aid=432532group_id=3152
[AOLSERVER] client/server software with AOLserver
Hello. I've been writing a nice and easy to use DB module. The webpages side works fine, but I want to write a client-server software for editing tables. I want to know if anyone's used AOLserver for server with Tcl/Tk for client and which technology should I use? I once noticed a project to integrate TclSOAP into AOLserver. What's the status of this project? Is it production stable? -- WK
Re: [AOLSERVER] client/server software with AOLserver
Wojciech Kocjan wrote: Hello. I've been writing a nice and easy to use DB module. The webpages side works fine, but I want to write a client-server software for editing tables. I want to know if anyone's used AOLserver for server with Tcl/Tk for client and which technology should I use? I once noticed a project to integrate TclSOAP into AOLserver. What's the status of this project? Is it production stable? -- WK we do a lot of this. the simple/obvious approach we use is 1) to make all your server side/ db access functions accept/return things into tcl lists or serialized arrays. 2) make simple url handlers that are wrappers for the above functions your tcl tk programs can then use the std. ::http package to get /put data to/from aolserver as tcl lists or serialized arrays your adp pages can call the same procs without the url handler wrappers and process it into whatever html it desires now you could formalize all this to a large degree using something like soap but it's probably not worth it unless you need a formal API for programmers outside your immediate circle of development. i have found it pretty easy to just informally sling around tcl lists. if there was a ready-for-primetime soap package out there. i would consider using it though. as far as i know there is not one quite at that point yet. there is an nssoap project on source forge but it's not ready for immediate use last time i looked. you can poke around at http://sourceforge.net/projects/nssoap/ -- Mike Hoegeman Email: [EMAIL PROTECTED] Phone: 805-279-7306
