On Fri, 11 Apr 2003, The Purple Streak, Hilarie Orman wrote:
It's desirable to avoid the round-trip latency whenever possible. It
seems eminently possible and sensible to do this for SMTP. That lets
one have an architecture with a centralized content-driven dispatcher
(OPES processor) but without round-trip latency between the OPES
processor and the callout server.
There is no round-trip latency in a simple implementation of your
example: There is no callout server and OCP. There is no "bump on the
wire" to introduce that latency. There are just two sequential hops
(two OPES processors) on the wire, pipelining as fast as they can.
If you insist on using OCP and a callout server, then there is still
no extra round-trip latency as long as both OPES processor and the
callout server can handle "I took care of it, forget it" mode of
operation that I described earlier. No modifications to OCP core are
required to support that mode on per-application basis. That mode may
be useful to implement black holes, for example (but I am repeating
myself).
Do you think we should add explicit "I took care of it, forget it"
support to OCP Core? Even though some connection-oriented application
protocols like HTTP cannot "forget" a message on a protocol level?
Thanks,
Alex.
On Fri, 11 Apr 2003 at 07:02:23 -0600 (MDT) Alex Rousskov murmured:
On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote:
> As has been mentioned before, because friends of OPES would like to
> deal with OPES and its callout protocol for all content
> transformation tasks. Just makes life easier.
You have to provide a better (more detailed) motivation than that. In
your specific example, sending the message to the next SMTP hop is
actually "easier" than handling OCP. Moreover, any OPES processor that
supports rule language would already have the functionality to send
application messages to their next hop as opposed to a callout server
-- it is a common case in real-world rule sets or ACLs, and we are not
adding anything "new" here.
Alex.
> On Thu, 10 Apr 2003 at 21:57:26 -0400 Markus Hofmann mused:
> > The Purple Streak, Hilarie Orman wrote:
>
> > > I had a returned thought on the issue of whether or not data had to
> > > complete the loop between the OPES processor and the callout server.
> > > If the proxied protocol is a store-and-forward type, like SMTP, then
> > > it seems that the callout server might, quite properly, send
> > > transformed messages directly to an application endpoint (SMTP
server)
> > > without going back through the OPES processor.
>
> > If that is the case, why would you need a callout protocol in the
> > first place? Why wouldn't "OPES processor" and "callout server" talk
> > SMTP between each other? "OPES processor" and "callout server" would
> > just be two mail servers talking SMTP...
>
> > -Markus
>