Re: No OPES WG Meeting in PAris
"Hector Santos" <[email protected]> Wed, 13 Jul 2005 14:19:35 -0400
| Newsgroups | gmane.ietf.opes |
|---|---|
| Organization | Santronics Software, Inc. |
| Message-ID | <001f01c587d7$6eccc880$6401a8c0@hdev1> |
----- Original Message ----- From: "The Purple Streak, Hilarie Orman" <[email protected]> > I have several issues. > > 1. Should the language be able to store metadata about message and/or > connection state? Should it be able to accept such information > from the callout protocol? I would say so. > 2. Should the rules be able to load data from files? Of course. But that may be independent of the client. > 3. Is there any reason not to include full regexp matching? That's an language implementation issue. Lets take a step back a little. Did I personally miss the Interface Requirements between heterogeneous processes? Or does this not apply? If this is going to work, I can only see this be done as a black box where some OPES service is exposed to the world, maybe as a WEB SERVICE for example in the backend. The issues I need to know is how to pass it the information it needs and how to get a result as I expect it. From a SMTP standpoint for example, there are five (5) process entities: CIP - Client IP address CDN - Client Domain Name SRP - Sender Return Path RFP - Recipient Forward Path DATA - Payload Plus maybe some server side USER information: UAI - User Authorization Information UPA - User Personal Account How much more can the SMTP receiver feed a OPES callout service? I mean, I don't care what the "language" is written in BASIC, APL, LISP, FORTH, FORTRAN, C++, D++, Z++ or what have you, I am more interested in the software engineering interfacing: Process <--> Callout You need to be able to defined a) how or what input is passed? b) how or what output is returned? c) will it have synchronous vs. asynchronous behavior? d) Timeout/Keep Alive issues (very related to C) Once this is written, the backend language is inconsequential. They all must offer the same level of interfacing. Today, you write this "language." Tomorrow, someone writes in BASIC maybe just because they believe its makes it more marketable . In either case, the interface must be the same. If I missed any of this in the technical specifications, I would really like to see it. Thanks -- Hector Santos, Santronics Software, Inc. http://www.santronics.com