ietf-openproxy
[Top] [All Lists]

Re: FW: feedback: OCP version head_sid2 thread: Try 2

2003-04-08 03:24:52

At 21:53 07/04/03, Alex Rousskov wrote:
On Mon, 7 Apr 2003, jfcm wrote:
> Would these sessions represent the whole message transiting through
> OCP towards as many services as required ? If yes I would accept the
> concepts. Interaction otherwise? A session would be all the OCP
> interactions that a message may perform from the dispatcher to
> services until sent to the user. So you could talk of the OPES
> session. Makes sense in French, but I do not know if it is the same
> in English.

If "many services" are on different callout servers,

I did not say "many services" but "as many services as required".
- if there is one or there are ten this makes no difference
- there must be no asumption of where a service process is located.

then your definition of "session" makes sense, but seems to be out of OCP scope since OCP is concerned with single processor - single server communication.

Tracing should keep track of previous OPES applied to the message. To prevent loops. This builds the concept of a session (exit the session in case of loop).

If the services are on the same callout server, then
your "session" would be in OCP scope. It would be something that may
cross OCP connections even. I am not sure why we would need it though.
To be able to abort easier?

The question was about using the word session to another end. I explained what "session" meant to me, and I think it makes sense and can be used. Abort is one reason I quoted, yes. There may be others like to understand the order of the previously applied services, etc.

> You sure you want to use OPES Processor the way you do?
> For me it is opposed to every standard thinking I know.

Not sure what you mean. OPES processor is just an application proxy
that outsources processing of some messages. Sounds pretty "standard"
to me. Is it not?

Documented that already. To me a a processor is where an process occurs. An OPES is a service. So to me OPES Processor is where the service process occus, ie on what you call the call-out server. On what you currently call the OPES Processor only happen the dispatch of the call-outs.

An addition confusion is if I use another archtecture than the dispatcher/call-out to implement OPES. I will use daysy chained OPES Porcessors where the servies will be provided if some conditions apply.

jfc