11:06 p.m.
Hi Ludo,
So, the questions are:
- Do we want to be able to run multiple connectors on the same device?
Since it's not really clear to me what a connector is going to be yet,
let me say that we definitely want to be able to support more than one
IPC mechanism simultaneously on the same device. On linux this is
likely to be d-Bus and websockets. We will probably want to allow users
to enable and disable IPC mechanisms.
It's not clear to me yet whether we will be able to have a single
generic process for all OSs or whether it would be better to have a
linux specific process in which d-Bus is always available and websockets
can be optionally disabled. I suspect the latter would be the easiest
but this remains to be seen.
- Do we want a service/server by connector or a single service/server
that run all connectors?
As far as I can tell we cannot have two separate processes providing DMS
APIs over different IPC mechanisms as this will lead to redundant
network traffic.
- Do we want a single service for DMS/DMR or 2 separate services?
For me, the simplest thing to do, with the least architectural and API
changes is to have one process for the DMS API and one process for the
DMR API, which is what we have today. The only change will be to
modifying the existing processes to support multiple IPC mechanisms. We
will change the APIs, but not for architectural reasons. They will
change merely because we are renaming everything to dleyna-*. These
changes will therefore be cosmetic.
Combining both APIs into one service would require big architectural and
API changes, and I can't really see any benefit in doing this.
Regards,
Mark
12:59 a.m.
New subject: Re-Arch: Rename and split components
On 24/01/2013 13:06, Mark D Ryan wrote:
Hi Ludo,
> So, the questions are:
>
> - Do we want to be able to run multiple connectors on the same device?
Since it's not really clear to me what a connector is going to be yet,
A connector is more or less a techno: Dbus/websocket/binder/
let me say that we definitely want to be able to support more than
one
IPC mechanism simultaneously on the same device. On linux this is
likely to be d-Bus and websockets. We will probably want to allow users
to enable and disable IPC mechanisms.
Ok with that.
It's not clear to me yet whether we will be able to have a
single
generic process for all OSs or whether it would be better to have a
linux specific process in which d-Bus is always available and websockets
can be optionally disabled. I suspect the latter would be the easiest
but this remains to be seen.
Not sure to understand "all OSs".
We only run on Linux (Android = Linux with some specific flavors)
We could have the same behavior with Binder+websocket
> - Do we want a service/server by connector or a single
service/server
> that run all connectors?
As far as I can tell we cannot have two separate processes providing DMS
APIs over different IPC mechanisms as this will lead to redundant
network traffic.
That would be possible. I just think Regis doesn't plan to implement it this way.
This is more work. Need to talk with him.
I think we need to sit around a table with a coffee and discuss this technical option :)
> - Do we want a single service for DMS/DMR or 2 separate
services?
>
For me, the simplest thing to do, with the least architectural and API
changes is to have one process for the DMS API and one process for the
DMR API, which is what we have today. The only change will be to
modifying the existing processes to support multiple IPC mechanisms. We
will change the APIs, but not for architectural reasons. They will
change merely because we are renaming everything to dleyna-*. These
changes will therefore be cosmetic.
Combining both APIs into one service would require big architectural and
API changes, and I can't really see any benefit in doing this.
I'm fine with this option. It's the simple one.
I just thought that for developers it should be easier to manage a single d-bus service.
Ludo
1:28 a.m.
New subject: Re-Arch: Rename and split components
Hi Ludo,
> It's not clear to me yet whether we will be able to have a
single
> generic process for all OSs or whether it would be better to have a
> linux specific process in which d-Bus is always available and websockets
> can be optionally disabled. I suspect the latter would be the easiest
> but this remains to be seen.
>
Not sure to understand "all OSs".
We only run on Linux (Android = Linux with some specific flavors)
We could have the same behavior with Binder+websocket
Right, so really what I was wondering here is whether we want to have a
single DMS process that will run on both standard linux and android,
which uses some sort of plugin mechanism to load connectors, or whether
we want one program for standard linux and one for android.
I'm fine with this option. It's the simple one.
I just thought that for developers it should be easier to manage a single d-bus service.
I can't see how it makes much difference from the developer's point of
view. They still need to call g_dbus_proxy_new_for_bus for each d-Bus
object/interface pair and bundling everything together won't reduce the
number of object/interface pairs that need to be manipulated. Even if
we combined the two Manager Objects we would probably need to create
separate interfaces to separate the DMS and the DMR specific functions.
I guess having a single service might be less work for developers using
code generation tools to generate their d-Bus bindings. With one
service, they'd only need to run the tools once I suppose, but I'm not
sure it's worth changing APIs and architectures to avoid this.
Regards,
Mark
3524
days inactive
3524
days old
2 comments
2 participants
participants (2)
-
Ludovic Ferrandis -
Mark D Ryan