[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Shortcuts
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
> >