Lightweight RPC over BEEP

Hi,

We are looking for RFC definitions to perform some lightweight RPC over
BEEP between applications on the same desktop. As a first choices for
RPC definitions we have found XML-RPC definition (RFC3529) and SOAP over
BEEP (RFC3288bis-02). 

Because SOAP encapsulation protocol covers many things not really needed
by our environment, we find RFC3529 to be the right choice. However I'm
trying to contact the RFC author to ask some question about the document
but it seems the address is no longer available. 

Here is the mail I've sent to the author. Maybe the RFC author is still
earing this mailling list and some of you could add some comments about
it (that would be really appreciated!!):

---BEGIN MAIL
We are considering to implement the RFC 3529 profile definion on top of
Vortex Library [1] to perform application IPC inside the same desktop. 

We think it fits right for the kind of lightweight IPC we are looking
for, however, I would like to ask you some questions we have found. I
hope this is the right way to do this.

1) Why did you choose the XML-RPC defined at [2] as the XML definition
for the BEEP profile? Why not define other XML-RPC at the RFC itself?

2) What is the status of the RFC? What makes this RFC to keep on
experimental state? Do you think we shouldn't implement this profile
because there is something that makes this profile to remain
experimental or not usable?

3) Bootstraping mechanish you have defined at "2.1 Profile
Initialization" section is great. We think it is a good fundation to
enable registering new XML-RPC interfaces to be exposed on real-time.
Was this idea the main purpose for the profile initialization to be
designed this way or it was something else different?

4) Knowing we are going to use this RFC to implement a kind of IPC
between applications on the same desktop, did you find this to fit right
or there are better BEEP profiles to accomplish this task?

5) Because we are going to run several components exposing interfaces on
top of the XML-RPC mechanism, we need some kind of location broker to
implement the next steps:

  a) Connect to the location broker and request current location for a 
     given component using logical names, for example:

          "common::component-name"

  b) The location broker returns the location for the
     component named "common::component-name" to be running at:

           xmlrpc.beep://localhost:64000

  c) Finally connect to that host location where it is expected to find
     a BEEP peer implementing the XML-RPC profile.

So, the question could be: Is there some BEEP RFC defining this kind of
location broker (not matter if it is being defined at this moment)? 

Thanks for your attention, 

Cheers!!

[1] http://vortex.aspl.es
[2] http://www.xmlrpc.com
---END MAIL

Futher reading shows that item 3) is not right. Bootstraping mechanism
was defined on SOAP over BEEP RFC and later adopted by RFC3529. However,
it is still a good mech no matter who have defined it first.

We are especially insterested on item 2), that is, why RFC3529 remains
experimental? Our felling is that the XML-RPC doesn't support any
transaction identifier that could ensure correlation, so this could be
the problem that explain such state. It this right?

About the item 5), the location broker issue, is there any effort on
this direction? 

We think it could be a great definition to have the ability to connect
to a location broker and discover on real time more BEEP peers running,
based on different factors, performing later connections in a
peer-to-peer manner withtout the intervention of the location broker.
What do you think about this idea?

Many thanks for you attention!

-- 
Francis Brosnan Blazquez <[email protected]>
Advanced Software Production Line, S.L.