At 01:18 14/07/2005, The Purple Streak, Hilarie Orman wrote:
On Thu, 14 Jul 2005 at 00:10:57 +0200 jfcm mentioned:
> - I name CRC (common reference center) a clearing house for common
> information to the members of a relation, community, etc.
> - I name "shuttle" the one shot transaction which ask the CRC one
> information identified by its number, associated to a tag (ex.
$list_name/1001)
It's called on RPC in the literature.
It may be supported by RCP variant. But the transaction make no difference
if the CRC is on the same machine or not, or on local network (for example
qnet)
> - I name "spice box" (shuttled private information cache exchange) the
> cache of the data received from the shuttled or processed from them. let
> consider it is an opposite to the cookie (my secret knowledge of the
> external world).
Like a DNS cache, like a proxy server for http, like any number of
other caches for various protocols?
Yes. Except that the information may be processed or deducted. An
application can be cronned or triggered by some entries. The important
point is that I can process the information or call for a replacement by
another value from another source.
> This means that when in a text the filter needs to replace $list_name by
> its value, it will call the 1001 in the spice box which in turn will call
> on the CRC.
Always, or only when the information is stale?
Always. This is "my" view of that information. A variable.
> I am interested in having the shuttle authenticated.
With respect to what? The client authenticates the shuttle, the CRC
authenticates the shuttle? Who authorizes shuttles?
The shuttling must be secure (I must authenticate the return) and the
delivery of information may be protected (I authenticate the request). I
(user) and CRC master authorise shuttles. Possibly under a relation controller.
> In most of the case the shuttle transaction will be one datagram. And be
> used to also to carry a command/signal. So UDP seems adequate. But
when the
> transported information is longer, OCP could be of interest?
Why not use TCP?
Why not, but seems heavy. Quite comparable to DNS. Timers can be freely
decided by the application.
> Then obviously
> this system is destined in interrelating (on my machine, under my
control)
> with the applications such as SMTP.
What's the architecture? Does your SMTP server call on the CRC to get
extra information? Does your SMTP client call on the CRC?
Any architecture can be thought of. Let think about the spice box as a
dynamic extended locale.
> Obviously the information of the CRC is more static than in OPES
(call-out
> servers can be quite dynamic).
We hope not.
Why? This is the interest of an OPES vs a middle-box?
> But CRC will use IPv6 access grids. This
> means that each information will be related to a number which is an
> InterfaceID. So one can call many CRCs to get/prioritised environment
> (something OPES could also do).
Sounds horrible. Surly you don't want to tie application information to
InterfaceIDs?
Sure we do. We do not relate "application information" but "protocol
information". The Grid is part of the Protocol. Like ports could be in RPC.
Are you talking about using Anycast to collection of CRC replicas?
Nothing opposes if the replicas are identical (ex. distribution of IANA).
But the interest is that the spice boxes can be fed with prioritized
information from different servers. So, I can get context information from
a given CRC and referent information from another one and default from a
locale like source.
If your primary question is, could OPES be used to implement a caching
service for a nearly stateless RPC protocol, I'd say not really. OPES
would be relevant if you already had such a service and wanted to
provide added value to it with callout servers.
Or, suppose you were using OPES for SMTP enhancements already, and you
wanted to add CRC information. We had already decided that in such
cases, the callout server would be responsible for retrieving CRC info,
and it would cache it if needed.
I just mentioned it to help my thinking on the issue and as an example of
the architecture some cases could work with. The OPES concept is that it
runs on a proxy and the callout server is distant. The spice box is on the
user machine and dynamically build its vision of the world. One application
can actually change that vision from an SMTP input. For example, if an OPES
tells a call-out server the origin of mails, that server can call an
application running on the spice box, the information is used and an
information in the spice box changed that can be sent to the all-out server
to permit a response to the OPES.
This can permit me for example to tell my machine where to send a mail,
depending in the time it comes in, of its sequence and where I am, while
all these informations are randomly feed.
I am very interested if you have advises on the RPC tools (center of
expertise, specialists, ...) I will spend my vacations on RCP, ISO 11179,
ASN1. etc. :-)
jfc