Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of a.broekhuis@gmail.com
 designates 209.85.217.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9b2b2807bfd920c20a3bf53d3edd967c.squirrel@46.19.35.7>
References: <9b2b2807bfd920c20a3bf53d3edd967c.squirrel@46.19.35.7>
Date: Thu, 23 May 2013 12:01:18 +0200
Message-ID: 
 <CA+T-u8ebtsqqNf25h=5ZDNMbgvnx+LmkT8h+6=Gr+YUEGr9EiQ@mail.gmail.com>
Subject: Re: Remote service transport system
From: Alexander Broekhuis <a.broekhuis@gmail.com>
To: celix-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=001a11c34ae682bc8804dd5fc31c

--001a11c34ae682bc8804dd5fc31c
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Thanks for the message and your work regarding remote services! Looking
forward to your implementation!


> So to summarize: What Transport system should I implement? ZeroMQ and
> introduce a dependency and maybe a legal issue.


For me this is still unclear. So hopefully one of our mentors can advice.
The referenced page mentions including LGPL code, are we (Celix) including
any of this? Or do we expect the user to install ZeroMQ and do we only
"include" header files in our code? If so, is it then allowed? If not, why
is "including" GCC headers allowed? They are GPL, not even LGPL.

I do think however that is important that we do not distribute any of the
ZeroMQ code, or binaries which are static linked with ZeroMQ.

As said before, I am not sure, hoping that any of our mentors can help us
out here.


> A message queue system
> from the list above? Or build it in TCP?
>

>From a technical point of view there is nothing wrong with having multiple
implementations. The current Remote Services code doesn't make this simple,
but I'd like to invest some time in a more pluggable system for this.
But for now a new RemoteServiceAdmin implementation can be made.

As for an alternative, using an existing implementation might be
worthwhile, especially when we want to connect to Java OSGi. This implies
the system has to have a C and Java binding/implementation (which isn't a
problem if I look at the list).

But having a dependency on a large third party system might as well be a
drawback in some cases. It creates an additional dependency for the user.
For example, I assume all of the messaging systems require some server to
be setup/started. For larger and real life systems I don't think this is a
problem. But for someone who is just interested in OSGi, Celix and remoting
this might be an issue.

So from that point of view I'd love to see a "configuration-less" solution
(ie, no external setup/config other then in Celix self). But I also welcome
a more complex solution with an existing message system.

So I think this mostly depends on your own needs/time.

-- 
Met vriendelijke groet,

Alexander Broekhuis

--001a11c34ae682bc8804dd5fc31c--