On Thu, 6 Mar 2003, jfcm wrote:
On 03:58 06/03/03, Alex Rousskov said:
OPES protocol is not meant to be a general-purpose plugin interface.
I do not see how an OPES protocol (between dispatcher/server) can be
an interface? You mean "plugin access protocol"?
Any protocol is an interface. In our case, the interface lets
integrators plug a callout server into an OPES processor. In the IDNA
case, there could be a browser plugin protocol/interface that lets
users add IDNA conversion plugins to their browsers (without modifying
browser software or the plugin, of course).
What you describe is a good application for a browser plugin,
Again, the browser has NOTHING to do in here. You introduced it.
I talked about IDNA and you decided IDNA was on the browser.
I did not decide. I just suggested it as an example of where IDNA
conversion would work well. According to IDNA draft, IDNA conversions
are done in a user application. A browser is a well-known user
application. It is just an example.
I only say it is an application on the process which consistently
manages the transcriptions of UTF-8 entries into ACE labels.
for web, mail, ftp, etc Many IDNA may exist on a machine, only
one can do it consistently and hopefully completely. I will chose
to name the place where that process is triggered the "user
control system" (because I observe on the market that it is
what is proposed/under proposition).
The user control system should by essence not be an
application of the browser. The browser should be a peripheral
of it, or it should run in parallel to the browser and use it
as a screen.
In your example, the IDNA conversion software is plugged into the
"user system" and other system components (such as browser) may
recognize and use it as necessary (probably via some kind of "plugin"
service interface). That's a fine example, and I suspect that is how
many new/patched systems could support IDNAs.
Still, my reasoning remains valid, I think: One cannot do IDNA
conversions outside of the user application (the application can, of
course, use "user system" resources like in your example, but that
does not change anything). This limitation puts IDNA out of OPES scope
because "users" and their applications are out of OPES scope. Again,
OPES is a proxy service. IDNA conversion (in both your and my
examples) is not.
I am just trying to answer your original question (see the Subject:
line)...
[ good stuff about user control systems snipped ]
The callout protocol, if it is good; may be used between the
user control system (see below) and its related servers. It
may also copy from it if the user control system comes first.
What may be/is is the case.
...
The last step is the relation of the user control system
(dispatcher) with other dispatchers: OPES on the path of the flows
or other user control systems, the user control system is in
relation with. This may be on the fly. This may also be a lasting
cooperation, with shared services. I call them ONES because they are
open (to several users choosing them), networked, they extend the
capacity of the relation, with its own processing assistance, into a
computer assisted networked continuity of services.
It looks like you are investigating whether user control systems can
benefit from talking to OPES agents and how such communication might
change OPES. If that is your motivation, this group should certainly
consider any new requirements that your use cases may mean to OPES.
You have to drive this discussion though (e.g., by submitting
OPES-specific use cases or requirements). Are you saying that IDNA
conversion has some influence on OPES? If yes, what is that
influence? If no, why are we talking about IDNA (should we talk about
user control systems instead?)?
Thanks,
Alex.