Subject: [BEEPwg] Lightweight RPC over BEEP

From: Francis Brosnan Blazquez <[email-masked]>
Date: Thu, 29 Dec 2005 22:36:28 +0100

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-masked]>
Advanced Software Production Line, S.L.

_______________________________________________
BEEPwg mailing list
[email-masked]
http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg

---

From: Francis Brosnan Blazquez <[email-masked]>
Date: Fri, 30 Dec 2005 18:58:23 +0100

El vie, 30-12-2005 a las 09:06 -0500, Peter Hall escribió:
> Francis

Hi Peter!

> 
> Just a quick thought about your location service.
> 
> I can think of 2 possible ways to do this.
> 1) LDAP - http://www.openldap.org/software/
> 2) DNS Service Discovery -  http://www.dns-sd.org/
> 
> I've not implemented a location service but I know both of these
> solutions
> are capable of doing it.

Thanks for your reply, I'll take a look into DNS Service Discovery. 

I feel both are centralized location service solutions for large
networks (and not so large ones ;-) that could allow to find new BEEP
servers that are allways located on the same host:port place (maybe
changing the port part). However we have already implemented that server
location behaviour in the middle-ware we are working on called Af-Arch
[1].

But, at the client side, to perform desktop IPC between applications to
compose bigger ones running on top of Af-Arch we have realized that,
already being attached to a BEEP engine, why don't use that engine to
connect to other components thourgh an lightweigh RPC rather than going
to use other IPC?

In our environment we have several desktop IPC solutions, the one that
could fit well is D-BUS [2], but they don't seem to understand that
people not only want's to produce KDE and GNOME desktop based
applications, because customer are mostly running windows!! (for D-BUS
people, windows desktop doesn't exist, and that's ok [3])

If you look inside D-BUS source code, you'll find that they are
reimplementing (*again*) many concepts already address by BEEP. So, we
could say we are looking for:

1) Reuse the BEEP engine, that our applications is already attached, to
implement a portable (starting for GNU/Linux and Windows) IPC mechnism
that, if posible, to be one an already defined RFC. At this moment we
are mostly sure that XML-RPC (RFC3529) is a good starting point.

2) Find and implement (or just implement) a mechanism to discover inside
the same desktop more BEEP peers exporting component interfaces on top
of previous defined mechanism. 

Thanks for your comments Peter, feedback is allways appreciated!!

Cheers,

[1] http://fact.aspl.es
[2] http://www.freedesktop.org/Software/dbus
[3] http://dbus.freedesktop.org/doc/dbus-faq.html (item 18)
> Regards
> Peter