Hi Ludo,
On Thu, 2013-01-24 at 11:01 +0100, Ludovic Ferrandis wrote:
>
> I'd just like to make sure I understand what you are proposing before
> commenting. If I understand correctly, your suggestion is that we have
> one d-Bus service that provides APIs for discovering and manipulating
> both DMSs and DMRs.
Yes.
>I guess this service would expose a single Manager
> interface, containing the methods from both
> com.intel.MediaServiceUPnP.Manager and
> com.intel.RendererServiceUPnP.Manager, and then one object for each DMS
> and DMR detected.
>
Yes. Maybe we should change some methodes and signals name to avoid confusion.
GetRenderers instead of GetServers (already exists for DMS) and Found/Lost Renderers
instead of Found/Lost Servers (same, already exists for DMS)
> If we wanted to provide access to DMSs and DMRs through a different IPC
> mechanism, e.g., websockets, a separate service would be run.
>
Yes, each "connector" run as a separate service.
Okay I think I've got it now. So the main problem I see with such a
solution is that if we wanted to support two IPC mechanisms at the same
time, which is one of our goals, we would end up with two separate
processes. Each of these processes would presumably need to perform
device discovery, which would lead to extra network traffic, one of the
things dLeyna is trying to avoid.
Assuming I'm correct here, we could solve the problem by having a single
dLeyna process that supports multiple IPC mechanisms and provides both
DMS and DMR APIs. However, I'm not sure this is a good idea either.
As discussed above, we would also need to make reasonably large changes
to the API. I was hoping the only change we would need to make during
the re-org would be to rename the services and perhaps the names of the
interfaces and objects, but that all the methods, properties and signals
would stay the same, thereby minimising the impact of our re-org and
more importantly, my task of updating the webpages :-).
In addition, I think the APIs will be cleaner if we keep them separate.
Also, I'm not sure I like the idea of having one process that provides
APIs for both DMSs and DMRs. The problem is that we don't know at
compile time what applications the users are going to launch. Let's
assume the user launches an application that does two-box push and that
dLeyna is not running. The user only needs needs to know about DMRs.
If we combine the two APIs into one process, dLeyna will perform both
DMS and DMR discovery when he launches his app (and dLeyna is itself
launched by d-Bus activation), even though no-one is interested in DMSs.
Yes, to resume, the question is, should we have a single service by
connector, merging DMS/DMR API, or should we have 2 services by
connector, one for DMS, one for DMR.
For these reasons, I think it would be better to keep the current
architecture in which we have separate services for the DMS and the DMR
APIs. However, each of these services need to be capable of handling
requests from multiple IPC mechanisms. The common code for these
processes being factorized into one or more shared libraries.
Regards,
Mark