Parallel call-out server requests will be useful for delivering different
services on same content to different content consumers. For instance, an
intermediary could act as a multicast overlay node serving the same content
to several consumers in different languages . In this scenario, there is no
dependency between services provided by different call-out servers.
Govindan
"The Purple Streak (Hilarie Orman)" wrote:
The intermediary can certainly keep track of A, tr1(A), and tr2(A),
where A is an object (stream), tr1(A) is A transformed by service type
1, and tr2(A) is A transformed by service type 2. The intermediary
might delivery A immediately to satisfy some requests (even forwarding
the stream packet-by-packet as it arrives), serve and cache tr1(A) for
some requests, and cache tr2(A) for a different period of time and
server different requests with that data. That's the simple case.
It seems relatively straightforward, if we are talking about the
same thing.
Hilarie
Markus Hofmann wrote:
Hi,
I agree that parallel service requests (actually to totally different
call-out server) are very powerful, but the callout server would never
known by its own whether its modifications on the message are going to
affect other services or not. [...]
I agree, and it seems there might be several different approaches to
solve this problem, but each of them would add some complexity to the
system.
So, a general first question is whether we would like to allow parallel
service requests on the same message or not. What are the expected
benefits and do they justify added complexity? Any opinions?
-Markus
--
Govindan Ravindran Email:
gravin(_at_)somanetworks(_dot_)com
SOMA Networks, Inc. Phone: (416) 348-1558
312 Adelaide St W Fax: (416) 977-1505
Toronto, ON M5V 1R2