At 02:26 07/03/03, Alex Rousskov wrote:
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).
Accepted. Unfortunately not the case. Hence my question. IDNA
is an accepted universal need. The initial support of the IDNA and
probably for still some time is through a plugin. That plugin is of
no real interest if it is a browser oriented service, because was is
really needed is resolver front-end, for all the local applications.
However if the IDNA is accepted as an OPES service on the http
and the smtp path, we may specify and see implemented callout
protocol on the http/smtp output. Actually offering a hook for many
other services hosted on the very machine of the user/provider.
> >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.
Your reasoning is valid as long as you decide that the IDNA
application applies to the browser or to the mail agent. I say
that the IDNA is far better located at the user control system
because the IDNA is actually one small building block of the
IRL (Internationalized URL) of which the other services will not
be standardized before long, while they start being widely
used.
I am just trying to answer your original question (see the Subject:
line)...
I fully understand. I also consider that this may be the last
chance to see the real IDNA being specified by the IETF before
it comes out of control.
[ 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.
Yes. But the first question is: is the user control system as I define
it an OPES dispatcher as it seems it may do a lot of things that
OPES are not supposed to do:
- change the URL (redirect)
- be multilingual (IDNA++)
- interact with the user
- keep permanent user informations, etc.
But at the same time it may relate with services in using the
callout protocol, interact with other dispatchers, etc.
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?)?
You keep asking me to discuss cases. So I proposed a case.
That case is also a very current issue. But certainly the universal
multilingual standalone user control system is an issue of real
interest.
I think that its immediate interest could be to permit to define,
implement and test the upper level of the callout protocol: I
mean through local interactions withe services.
jfc
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03