[Cps4] CPSUniversal interface

[Eric Barroca]

Hi,

On 12 avr. 06, at 00:58, Ruslan Spivak wrote:
> В Пнд, 10/04/2006 в 15:02 +0200, Eric Barroca пишет:
>> 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.
The idea is that the component will expose a complete API on top of  
CPS, to allow to write components in other language.
If we have the event service plugged + a complete API, you can  
actually write services (like portal tools) on other languages, that  
would react to events and do stuff on objects, for example.


>> 	- 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 allow different CPS intances to communicate.
Like sending documents between two 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.
That's what I mean.

>> 	- 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.
yes


>> Principles :
>>
>> 	- A central client service that can be used to reach external ICE'ed
>> components
> can you, please, provide use case ?
Let's say we have JackRabbit, Lucene and Sesame available through ICE.
We need to have a central registry that list all services available,  
no ?
As far as I understand, ICEBox is designed for that.

>> 	- 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
components here == CPS products.
For example, CPSWorkflow can register methods available in the API  
exposed through ICE.
Same for CPSDocument, CPSCore, etc.

> 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?
It's a service, like CPSRemoteController, where CPS components can  
register methods available.
I do not know if it's inside or outside 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.
Well, typically, the CPSRemoteController for ICE would handle  
those .ice files.
And maybe serve them to ICE client.
 From another point of view, we could also add to this component the  
ability to serve the API using different protocols, like XML-RPC or  
SOAP.

> 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.
ok.

>> 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.
ok.

> 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.
ok.

> 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)
It need to be plugged with the event service.

> 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.
ok.
Let's try to make it work with IceBox for now.


>>
>> 	- 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.
And the Z3 publisher cannot be used to access Zope3 and Zope2 products ?
Florent ?

By the way, as I got some negative feedback with the name  
"CPSUniversal", I propose a new one "CPSRemoting".


Thanks,

EB.

--
Éric Barroca - Tel: +33 6 21 74 77 64 (mobile).
Nuxeo - Open Source ECM - www.nuxeo.com
CPS Platform - The open source ECM Platform
http://cps-project.org - http://www.nuxeo.com/en/cps