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.
Hilarie
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
>