I just think in simple ways:
- Yes/No.
- layers by layer implications
- logical models
- what has not been approved by consensus is not accepted
*At 17:51 16/04/03, Alex Rousskov wrote:
-- was "Subject: OCP questions"
jfc,
You keep mixing OCP and OPES which makes it very awkward (for
me) to respond. The "OCP questions" thread you responded to was about
OCP. OCP Core is application-agnostic and, hence does not care much
about proxied protocols, their conversions, etc.
The thread I followed was questions on that.
I took the liberty of renaming your Subject line. If you want
to polish or completely change OPES definition, PLEASE stay on this
new thread and make specific suggestions here. If you want to discuss
OCP Core draft instead, please use existing OPES architecture and the
old thread (or start a new one). I understand that OCP depends on OPES
architecture, but OCP thread is not about OPES in general, it is about
OCP. This new thread can be about what OPES is or should be.
The OPES is NOT defined enough for the OPC Core not to be affected.
At this stage I saw no concensus call on anything yet. Or did I
miss something?
Specific OPES-related comments are inlined.
On Wed, 16 Apr 2003, jfcm wrote:
> At 15:22 16/04/03, Alex Rousskov wrote:
> >On Wed, 16 Apr 2003, jfcm wrote:
> > > Most of the points risen here would get a clear response with a
> > > simple diagrams such as :
> > >
> > > http | data input | dispatcher | call-out protocol | server | call-out
> > > protocol | data-output | http
> > > <------ OPES ? possiblity 1
> > > <------ OPES ? possiblity 2
> > <--- OPES ? possibility 3
>
> >We already have/had such diagrams. Obviously, they did not provide
> >enough "clear responses".
>
> hmmm... This is your opinion which translates into some's difficulty
> to understand where we are.
What I said is not an opinion. It is a fact. We had very similar
diagrams in OCP Core (e.g., see section 2.1 "2.1 OCP environment" in
version head_sid3 of the OCP Core draft [1]) and, since people keep
asking questions, they did not get us "clear responses" you promise.
[1]
http://www.measurement-factory.com/tmp/opes/snapshots/head_sid3/ocp-spec.html#section_ops-environment
Since people still keep asking questions I suggest that you keep both the
diagram and the explaination. This may help to understand. So we may also
see if the diagrams are good enough and if the explanations match the
diagram. Modelization is the first step, but it is also an iterative process.
> If OPES is defined as the first possbility, http is part of it and
> call-out may take it into account. If it is defined the second way,
> external protocols are no part of OPES but OCP can consider knowing
> it. If it is the third definition (that I thought you would add by
> yourself in your response to illustrate the difficulty), then the
> call-out protocol has NO relation with the entry protocol.
I do not know what "possibilities" you are talking about. Are they
related to the arrows on your diagram? Care to define them explicitly?
I am discussing a diagram where three possibitilities are shown
with a question mark. For your convenience I added the wording
"possiblity #".
> >Note that OCP has nothing to do with "http |
> >data input |" and "data-output | http" parts. OCP Core has specific
> >wording about that. That wording replaced some of the figures that had
> >those parts in earlier OCP Core versions.
>
> Seems that this wording does not prevent questions. May be both
> could be kept? We could check they fit the different understandings.
By "both", do you mean the old figure and the new wording?
Yes. As discussed above. Even is things are the same in your mind, either
they will present the same thing and they will help understanding, or they
may present different things and will help indifying misunderstandings.
> > > PS. What about protocol conversion, is that OPES?
> >
> >It can be. An application proxy that does protocol conversion may
> >support OPES mechanisms and may be OPES-compliant. A decent HTTP proxy
> >today has to convert between HTTP and FTP (or even Gopher, WAIS,
> >etc.). I do not see why OPES proxies should be more limited than
> >existing HTTP proxies. If OCP is involved in protocol conversion, OCP
> >agents would have to negotiate/agree on how to specify
> >original/adapted protocols via application message metadata.
>
> At a given stage one must start saying what an OPES is and is not.
OPES is about many specific things. If you keep asking specific
questions ("Is OPES about Foo"), you will keep getting specific
answers ("OPES can be about Foo", but it can also be about "Bar").
This should not be the case. If you work out a, OPES diagram; you
will have I/Os and you will phrase OPES in a mathematical way as
a function (or group of functions). That function(s) will be clearly
understood if it is clearly and afirmatively described in a generic way.
If the I/O of the OPES black-box are data flows under protocols, then
OPES may relate to protocols, if not they will not. This is what a
diagram will permit/help you to see easily.
> And stop saying "it can be".
I was just answering your question! OPES, regardless of the
definition, can be many things. It is OK to say "OPES is about
protocol conversion", but since OPES is also about other things, it is
more accurate to say (IMO) that "OPES can be about protocol
conversion". That is, "protocol conversion" is within OPES scope.
The latter is the best wording, I guess.
No. As everything generic OPES can only carry what they have
beend defined to carry. Some implementations could do more,
they could also participate into some other process. But generic
OPES will do all what they are expected to do if they are well
designed, and no more (otherwise they would have been ill defined
or would cost too much to develop for the expected return).
> IMHO it CANNOT be a protocol converter if it is not related to the
> entry protocol
OPES _is_ related to the input/entry protocol. We even plan
input/output protocol-specific drafts, possibly one per proxied
protocol!
You "plan". This is "possibly". IAB said it is related to http.
To be realted to more you have two options:
- to draft as many OPES systems with impact on OPC
- to make them independent from the I/O protocol (possiblity
2 or better 3 aboe), leaving that aspect to a protocol interface
able to relate with such OPES systems.
I do prefer that last approach in one architecture (dispatcher centric).
I do not in the other architecture (daisy chaining). When you say
that OPES "can be both" you do not help me deciding.
We are here talking specifcally of the OPC Core. And in a
dispatcher centric architecture I think the callout protocol is the
center of the whole OPES system; while in the daisy chain
architecture If feel it is quite of no interest.
> (but the use of different I/O protocol will
> [affirmative mode] make it a part of a protocol conversion system).
Do not know what you mean by "I/O protocol".
Protocol used to input or output the data. The same
wording as you, just above.
> This will have an impact on OCP. The protocol sequence is then:
> http > call-out > smtp.
The above is not how callout protocol is now defined. Callout is
something that comes back:
(http) <--> OPES processor <--> (ftp)
^
|
V
(callout)
Thnak you for the draft/ So you can see that that the sequence
of the data path is http > (dispatcher) call-out (server) call-out >
(dispatcher) > ftp.
So if you only keep protocol, the protocol sequence is what
I indicated. It permits to see that - unless protocols conversion
or continuity relies on stored information every meta info in
the input protcol must be transported in the call-out protcol.
So the OPC is I/O protocol dependent and new versions can
be specified on I/O protocols basis.
Or OCP supports enough information to be mapped into many
protocols. Then all the protocols one can interface are OPES
acceptable.
This makes two totally different architectures and ways to
consider OPES.
jfc