[Cps4] CPSUniversal interface

[Ruslan Spivak]

В Пнд, 10/04/2006 в 15:02 +0200, Eric Barroca пишет:
> Hi,
> 
> I'd like that Ruslan initiate the design work of the CPSUniversal  
> module that aims at providing a unified interface on top of CPS.
> I may be based on ICE.
> 
> Goals :
> 
> 	- transparent access to CPS from other languages / platforms (Java,  
> C#, PHP) to allow development of CPS components in other languages  
> (ex: build your website using PHP and access CPS content).
Let's clarify a bit here: i think you don't mean here to write in other
languages than python full blown Zope components, but just Ice clients
in different languages to connect to Ice based CPS component that
provides predefined(?) API allowing clients to manipulate CPS in one way
or another.
I know we have some problems with CPSRemoteController API, it became
blown and custom projects have its own requirements for specific
methods, but i believe we could after thourough thinking provide API
that touches many aspects of work with CPS and create Slice definition
that will provide API methods for other languages.

> 
> 	- allow distributed achitecture for CPS development (CPS instances  
> can communicate)
What meaning do you put into this? Communication between CPSUniversal
components from different instances ?

> 
> 	- create a way to communicate with external components like  
> JackRabbit or Sesame using a unique way
If you mean here defining means of communication like Ice, then it's
clear how it can be unique. 

If it's about interface that is exposed by Jackrabbit/Sesame/etc, then i
do not see other way as if when using Ice, for example, to describe
Jackrabbit/Sesame/etc interfaces in Slice IDL which will be exposed
after that as Ice server's methods that will be accessing
Jackrabbit/Sesame/etc. Of course it's our responsibility to provide
those methods implementation.

> 
> 	- offer CPS connectors/API for Java, PHP and .NET/C#
> 
This is related to first goal, i guess, unless you mean something
different, ie provide API(defined with Slice) for manipulating CPS.


> Principles :
> 
> 	- A central client service that can be used to reach external ICE'ed  
> components
can you, please, provide use case ?

> 
> 	- A central service where components can register methods. The  
> service expose those methods to ICE clients.
> 
what do you mean here by "components" ? Can you expand, please? Is it
just python code that acts like Ice service and then it looks like
IceBox and component implementing interface just registers in IceBox(the
service/component code may connect to Jabber, for example, ie no
dependence on CPS).
Or it's component that exposes its methods via Ice and also has access
to CPS?

Let's start from the fact that before client and server communicate
invoking methods, we provide compile time(with python it's just load
time) contract using Slice IDL that we store in file and it should be
available both on client and a server. It's not xml-rpc that we add
method on server and client just calls it, client should also have
changed .ice file from server as well, to be able to call that new
method.
In Ice there is "untyped invocation and dynamic dispatch" mechanism that
allows to live without interface definitions with Slice, but this model
will quickly become complex to program, as many issues developer will
need to care himself.

> 
> Issues :
> 
> 	- Find a way to centrally manage all ICE components of our  
> architecture (ICEBox ?)
Actually i think it's IceGrid + IceBox for more complex installation, by
this i mean Ice services spreading on different hosts or serveral IceBox
instances on the same host - for example, 1 instance for java services
and 1 for python services. IceGrid will let aggregate them into one
service or just monitor their status, both possibilities are useful.

Not related to central management, but useful components:
Glacier2 - though it's router has special usage for bi-directional
communication between client and server, though it may be done manually.

IceStorm - plugs when there is need for efficient publisher-subscriber
features (here at once comes in mind AFP project with cache modification
events sent to CNG clients)

One note:
Currently IceBox is not available for python, only C++ and Java. If this
becomes issue in future we can ourselves develop necessary small bridge
C++ code using Ice infrastructure to have IceBox for python.

> 
> 	- Find a way to bypass the zserver and allow direct invocation from  
> ICE clients, without using a HTTP request
> 
First thing that came to my mind was using Zasync like approach, ie ZEO
client, but i'm not sure at the moment how well it fits with what
Florent does on Zope side.
With Z3 there may be other possibilities like using Twisted and
publisher interface implementation, but this should be verified and we
are not on Z3 anyway.

Ruslan