Re: shuttle/CRC

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.

>  - 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?

>  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?

>  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?

>  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?

>  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?  

>  Obviously the information of the CRC is more static than in OPES (call-out 
>  servers can be quite dynamic). 

We hope not.

> 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?  Are you talking about using Anycast to collection of
CRC replicas?

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 don't see any reason that the same machine that runs OPES couldn't
also run a caching proxy for CRC, though.  

Hilarie