On Wed, 26 Mar 2003, jfcm wrote:
On 19:51 26/03/03, Alex Rousskov said:
I think that the comment below refers to applying dispatch rules to
the result of a dispatch. I.e., assume the content is two parts,
{A,B}. That content triggers a modification to part B, resulting in
{A,B'}. The dispatch rules applied to {A,B'} trigger a modifiction to
A, resulting in {A',B'}.
OK. This seems to have nothing to do with OCP. This is about rule
processing, right?
No. the question was about a message definition and copying.
.. and copying is pretty much unrelated to an application message
definition! OCP dispatcher copies bytes (opaque message chunks), not
application messages.
I say you have two chuncks A and B. What may make or not one single
message.
OK. A single application message may be received and handled by OCP in
chunks. Each chunk belongs to one and only one application message.
(In between you responded that the message definition was
application dependent - what I have to digest as not my own
thinking).
Since [copied] flag applies to data chunks (not entire application
messages), the definition of a message seems to be irrelevant.
Application message definition is application dependent, by its very
nature (by definition if you will). I am not sure how you can have it
any other way. Care to explain? For example, RFC 2616 defines what an
HTTP/1.1 message is. No other spec defines that. However, OPES and OCP
are application agnostic. Whatever the message is, OCP treats it as a
bunch of opaque bytes. We just need to know the message boundaries,
nothing else.
The first dispatch rule leaves A untouched, so A can be sent.
Now the second rule says that A is to be modified.
You said above that "A" is a chunk. I think that rules should not be
applied to chunks, only messages, but it probably does not matter for
this discussion.
I did not say where the second dispatch rule is applied. It can be
on a cascading dispatcher or a loop back into the first dispatcher
before sending. Depends on the modelization.
IMO, OCP takes place when a single rule is applied to a single
application message. It does not really matter (from OCP point of
view) what happens before or after that. There might be 10 more rules,
but OCP does not know that and does not care. Why are you talking
about multiple rules in an OCP copying context? What is the relation
of rules to copying?
Where am I to find A depending on the cases?
- it may have been sent - if there are considered as 2 messages
- it may have been copied to a server and not returned since unchanged
- it may have been copied back
- it may not have been copied to the precedeing service
I do not think it is complex but it needs to be made clear.
Because we may certainly find cases where it is complex.
I do not know what you mean by "finding A". If "A" is a message, then
it may not have a single "location" because it is comprised of opaque
chunks, and each chunk may be at a different processing
stage/location. Recall that we are trying to use a pipeline model
here; each chunk will be at some processing point of the pipeline.
Moreover, until the pipe ends, it may be impossible to reassemble A
from "current" chunks because each chunk may be at a different
processing stage. Only when all processing stages are complete, you
can have a complete application message again. Furthermore, since the
application message chunks may be sent out as they "arrive" from the
pipe, there can be no single point in time where an OPES system sees a
complete application message. Finding message "A" is not possible, in
general! This is true for HTTP non-caching proxies, for example.
Alex.