"Robert J. Lebowitz" <[EMAIL PROTECTED]> wrote in message news:aqpfma.9e.1@;news.saltstorm.net... > I was intrigued by the idea of the Scope Engine and took a look at the code > to see what I could make of it. > > I haven't used XMail until today, so pardon me if I'm a bit ignorant about > its operation. I have written a short commandline application to substitute > for scope (.exe) that is designed to contact a Java Servlet, in place of the > Perl daemon that makes up the Scope Engine. My goal is to see whether I can > provide functionality extensions to XMailer written in Java, without the > need for JNI, etc. Using sockets to contact a separate server process > seemed like a logical approach for this sort of work. > > As with Scope, part of the goal is to reduce performance bottlenecks. The > Servlet can be running on the localhost, or a remote host, probably best on > the same LAN. > > Since most servlet containers precompile source to byte code, you don't have > to wait for that darn program to compile either. > > I noted in the limited Scope documentation that XMail doesn't look at any > output provided by the executable, only at its return (exit) code values. I > am a bit worried about one aspect of this approach, however, since there can > be some latency effects involved in using sockets. Does XMail start each > executable within a separate thread and wait for the return code?
filters and malproc "external"s are executed syncronously (in sequence) in the stated order. The XMail docs doesn't mention anything how the codes are propagated internally, but from the experience knocking up Scope I've learned that a filter responding with a 97, 98 or 99, will immediately cause XMail to break out of the filter queue. Any code other than 97-100 are treated as a 96. more about exitcodes here : http://www.xmailserver.org/Readme.html#domain%20message%20filters network latency shouldn't be a problem, if the server is unavailable, the client (talking scope.exe here) will go with a default exitcode of 0 within matter of a second or two (seems to differ somewhat depending on OS). A 0 code is taken by XMail as a 96. If the client<->server connection would hang in during a transaction for whatever reason, XMail has a configurable filter timeout (default is 30 sec I think) that'll step in and shutdown the client. Presumably this would be taken as a 96 code.. In any other case, the basic rule is; Xmail will wait for the client to complete, and the client will no do so until it receives a return code from the server. > I understand that there is some documentation on the return code values, but > could someone enlighten me as to what values I should try to output. Well, 96-100 are the one you should read up on, especially 96,97 and 100 as those are the one you will be using in 99% of the case). Apart from 96-100, XMail treats any other as a 96 (a no-operation). In the Scope server case I have a adopted additional ranges 200-210 and 230-254, as extended log-information about an what's going on. Indications about unexpected procedure errors etc. btw, As you might have noticed browsing the Scope client sourcecode I am no guru in the C area, so any suggestion improving it would be most welcome. I have re-posted your message to the xmail mailing list as there I are more people there that might have experience to share with you regarding this. Hope you don't mind. good luck. Thomas. > Thanks!! > > Rob > > (I'll post the code to a server after I've had a chance to test it and clean > it up a tad. Anyone with any ideas on servlets that would be useful to > have, please send your suggestions to me). - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
