Re: OPES protocol, pre-draft

Dear Markus and all,
please let not confuse everything in sticking to two terminolgies 
corresponding to twe different and quite opposed thinkings. This will help 
identfying these thinkings and to benefit from them both. Or we will wind 
up with something no one will be happy with.
At 19:02 17/03/03, Markus Hofmann wrote:
> You probably mean "OPES processor". Let's try to stick to the terminology 
> we've in the existing documents, might help avoiding misunderstandings.
Notwidthstanding the document I do not understand yet what is an OPES and 
what is an OPES processor - and it seems that I am not alone. But I fully 
understand what is a dispatcher and what is a server. I may be wrong, but 
for me a processor is a CPU, and a server an identified virtual system 
running on one or serveral CPU. I may be wrong, but I think in the case the 
server uses several cpus the callout protocol could/should be use to permit 
such cpu to interoperate?
Also I have difficulties in understanding if an OPES is the end-service as 
provided or the service as  provuided to the end-user. Meaning, if the 
dispatcher is part of the OPES or not. Meaning, if the dispatcher user side 
interfaces are parts of the OPES.
> > implementation that discards message chunk by chunk as soon as one is 
> > send to callout server does not look a good idea. Even if call starts 
> > before the complete message is received by the OPES processor it should 
> > be able to assemble the complete message anyway.
> This might require the OPES processor to possibly buffer huge amounts of 
> data, which might impact scalability of the approach.
For examplen that remark makes sense if the "OPES processor" is a single 
machine (otherwise "buffer" is to be defined). But an OPES service can be 
permformed on several machines (this is to be considered (?) or operated(?) 
by the callout protocol), either successively (the service processing calls 
on several machines) or in parallel (several mechines offer the same 
service and must coordinate).
> Imagine a large number of users simultaneously downloading large files via 
> HTTP, and the OPES processor
so, here you then mean dispatcher.

> does a callout for virus scanning for each of these files (in parallel). 
> Since virus scanning involves long delays in processing, quite some data 
> would accumulate at the OPES processor for temporary buffering...
This is true for any inputs (HTTP or not). This means that the callout 
protocol should not be dependent on the fact that the input is HTTP, but to 
support different levels of service that an HTTP flow may chose from, the 
same for an SMTP, or an FTP flow.
What I mean is that we have to be clear about the different layers, and not 
to patch through layer violations. Inputs come through a dispatcher. 
Dispatchers relate with other dispatchers (and servers? I personallythink 
that dispatchers should be server front-ends, much simpler) using the 
callout protocol.
Nothing in the callout protocol is to be directly related to what happens 
before the dispatcher. Alex,  shown well that towards the user (the user is 
to relate with the OPES through the application). This is also true the 
other way: the server is to relate with traffic flow through the dispatcher.
jfc