2:47 a.m.
Hi,
Currently, there are two main dLeyna repositories, renderer-service-upnp
and media-service-upnp, both of which contain d-Bus services for
discovering and manipulating DLNA devices. Unfortunately, the current
organization of the code is far from ideal and it's also an obstacle to
the evolution of our components.
1. The names of the repositories and services are meaningless and
cumbersome. They are derived from a long abandoned architecture and
do not appear to be connected with dLeyna.
2. There is a lot of code duplication between the two services.
3. The services are bound to d-Bus and we would like to support other
forms of IPC.
For these reasons we are planning to split the two existing dleyna
services into a number of new repositories.
Essentially, we plan to extract the common code from these two services
and place them in two separate repositories, dleyna-core for the common
code such as the logging, task handling, settings management etc, and
dleyna-conn-dbus for the d-bus code. Most of the remaining code in
media-service-upnp and renderer-service-upnp will be moved to two new
repositories, dleyna-renderer and dleyna-server. dleyna-renderer and
dleyna-server will actually be libraries. A small amount of code is
needed to create services out of them. This code for linux will be
stored in a fifth project, dleyna-linux. dleyna-linux will build the
d-Bus services but note that the names of these services will have
changed along with the project.
So to summarise, we are proposing to split the existing dLeyna code into
the following repositories:
* dleyna-core
* dleyna-renderer
* dleyna-server
* dleyna-conn-dbus
* dleyna-linux
All open issues in media-service-upnp and renderer-service-upnp will be
moved to the appropriate new repository. The old repositories will
still be available but they will no longer be updated.
In the future if we add a support for a new form of IPC, we will create
a new repository, e.g., dleyna-conn-websocket. If we support a new
class of DLNA or UPnP device we will also add a new project, e.g.,
dleyna-printer.
Finally, we will move the dleyna demo app, media-service-demo to a new
repository, called dleyna-control.
Does anybody see any problems or objections with this approach?
Regards,
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
10:03 p.m.
Hi,
The reasoning for a change you gave sounds really solid but I do have
some questions about this... I'm still just wrapping my head around
the whole thing so be prepared for questions that may, or may not,
make sense.
On 14 February 2013 17:47, Ludovic Ferrandis
<ludovic.ferrandis(a)intel.com> wrote:
So to summarise, we are proposing to split the existing dLeyna code
into the
following repositories:
dleyna-core
dleyna-renderer
dleyna-server
I know you guys must have thought about this but I'm just thinking if
the added complexity to developers (having to build multiple libraries
and keep them in sync) is worth the benefit -- I assume this means
dleyna-core becomes public API which is also additional work for
various people. For something like gupnp a smaller grained division
makes sense (because there can be developers who do not need all of
the libs, and the dependencies of the additional libs can be very big)
but is this really true for e.g. dleyna-core?
Basically, I'm trying to understand what the benefit is compared to a
single dleyna-* repo that produces libdleyna-renderer and
libdleyna-server that operating systems can then package as two
separate packages if they want to.
dleyna-conn-dbus
dleyna-linux
To make sure I've understood: dleyna-conn-dbus is one implementation
of the IPC that the libraries above are going to need, and
dleyna-linux combines one specific IPC method (D-Bus) and the actual
libraries. So dleyna-linux provides both D-Bus services but no
libraries?
If I understood this correctly, the same questions probably apply:
what is the actual benefit of keeping the ipc part of the library
outside the library (even if the part is going to be interchangable)?
I would assume it would be simpler to conditionally build only the
wanted connector than it is to define and maintain a public IPC API
and an additional project that combines the library/libraries and a
chosen connector.
By the way, what do you think about just calling them "ipc" instead of
"connector" (assuming that's what they are): I think that term will be
widely understood by most people. It's possible I haven't totally
understood the whole idea though and a new name makes sense.
Does anybody see any problems or objections with this approach?
I hope I didn't come off as too negative -- that was not the intention
-- like I said I'm still just jumping around the code trying to make
sure I even understand what's going on...
I agree that simplifying the setup would make a lot of sense sense but
I'm just concerned that adding lots of moving parts (and especially
APIs that are at least somewhat public) could be a problem later on.
Br,
Jussi
11:23 p.m.
Hi Jussi,
On 02/18/2013 12:03 PM, Jussi Kukkonen wrote:
Hi,
The reasoning for a change you gave sounds really solid but I do have
some questions about this... I'm still just wrapping my head around
the whole thing so be prepared for questions that may, or may not,
make sense.
On 14 February 2013 17:47, Ludovic Ferrandis
<ludovic.ferrandis(a)intel.com> wrote:
> So to summarise, we are proposing to split the existing dLeyna code into the
> following repositories:
>
> dleyna-core
> dleyna-renderer
> dleyna-server
I know you guys must have thought about this but I'm just thinking if
the added complexity to developers (having to build multiple libraries
and keep them in sync) is worth the benefit -- I assume this means
dleyna-core becomes public API which is also additional work for
various people. For something like gupnp a smaller grained division
makes sense (because there can be developers who do not need all of
the libs, and the dependencies of the additional libs can be very big)
but is this really true for e.g. dleyna-core?
Basically, I'm trying to understand what the benefit is compared to a
single dleyna-* repo that produces libdleyna-renderer and
libdleyna-server that operating systems can then package as two
separate packages if they want to.
We did consider putting the three libraries together in the same
repository, and for exactly the reasons you mention. In the end we
decided not to. I guess there were a number of reasons for this.
1. It is possible that someone might be interested in dleyna-renderer
and not dleyna-server, e.g., if they just wanted to implement 2-box push
and didn't care about media servers. Alternatively, someone
implementing a DMP would only be interested in dleyna-server. If we
bundle everything together it will be more difficult for people to
determine whether a change to the combined repository affects them ( at
the Github level at least). Note, that the two libraries have the same
dependencies so it's not currently possible to save on dependencies by
excluding one of the libraries. This may of course change in the future.
2. In there future there will probably be more libraries, e.g.,
libdleyna-printer, or libraries to interface with yet undefined DLNA
devices. We were concerned that a combined repository might become very
large going forward and that ultimately we would be obliged to split.
3. We thought it would be easier to manage issues ( again at the github
level ) if we kept things separate.
Now the question we need to ask ourselves is, are these reasons
sufficient for keeping everything separate? Will doing so over
complicate packaging?
Another option we considered was to bundle libdleyna-core,
libdleyna-server and libdleyna-renderer into one repository but keep the
libdleyna-core API public. Libraries for accessing other DLNA devices
would be placed in separate repositories. Ultimately, we decided not to
do this as we felt it would be easier to manage the issues if we keep
everything separate.
> dleyna-conn-dbus
> dleyna-linux
To make sure I've understood: dleyna-conn-dbus is one implementation
of the IPC that the libraries above are going to need, and
dleyna-linux combines one specific IPC method (D-Bus) and the actual
libraries. So dleyna-linux provides both D-Bus services but no
libraries?
Pretty much although I think the plan is that the connectors are loaded
dynamically at run time, so dleyna-linux currently doesn't know anything
about them. So dLeyna-linux basically contains some make files and a
small C file with a main loop and some signal handling.
If I understood this correctly, the same questions probably apply:
what is the actual benefit of keeping the ipc part of the library
outside the library (even if the part is going to be interchangable)?
I would assume it would be simpler to conditionally build only the
wanted connector than it is to define and maintain a public IPC API
and an additional project that combines the library/libraries and a
chosen connector.
The idea here was to avoid having a project that gets more and more
complicated as we add new IPC mechanisms. Also there will be IPC
mechanisms that are platform specific such as d-Bus and binder and we
thought bundling them together might get messy. Regardless of how we
organise these connectors, I think we will want to keep the connector
API public to allow 3rd parties to cleanly integrate dLeyna into
platforms that use custom IPC mechanisms.
By the way, what do you think about just calling them "ipc"
instead of
"connector" (assuming that's what they are): I think that term will be
widely understood by most people. It's possible I haven't totally
understood the whole idea though and a new name makes sense.
Sounds okay to me. Regis, is there a particular reason to stick with
connector?
> Does anybody see any problems or objections with this approach?
I hope I didn't come off as too negative -- that was not the intention
-- like I said I'm still just jumping around the code trying to make
sure I even understand what's going on...
I agree that simplifying the setup would make a lot of sense sense but
I'm just concerned that adding lots of moving parts (and especially
APIs that are at least somewhat public) could be a problem later on.
Not at all. This is exactly the sort of feedback we need. We only want
to do the re-org once so we need to get it correct. Feel free to
suggest a counter proposal.
Br,
Jussi
_______________________________________________
dLeyna mailing list
dLeyna(a)lists.01.org
https://lists.01.org/mailman/listinfo/dleyna
11:38 p.m.
Hi,
On 18/02/2013 13:23, Mark wrote:
Hi Jussi,
You was faster to answer :)
On 02/18/2013 12:03 PM, Jussi Kukkonen wrote:
> Hi,
>
> The reasoning for a change you gave sounds really solid but I do have
> some questions about this... I'm still just wrapping my head around
> the whole thing so be prepared for questions that may, or may not,
> make sense.
>
> On 14 February 2013 17:47, Ludovic Ferrandis
> <ludovic.ferrandis(a)intel.com> wrote:
>> So to summarise, we are proposing to split the existing dLeyna code
>> into the
>> following repositories:
>>
>> dleyna-core
>> dleyna-renderer
>> dleyna-server
>
> I know you guys must have thought about this but I'm just thinking if
> the added complexity to developers (having to build multiple libraries
> and keep them in sync) is worth the benefit -- I assume this means
> dleyna-core becomes public API which is also additional work for
> various people. For something like gupnp a smaller grained division
> makes sense (because there can be developers who do not need all of
> the libs, and the dependencies of the additional libs can be very big)
> but is this really true for e.g. dleyna-core?
>
> Basically, I'm trying to understand what the benefit is compared to a
> single dleyna-* repo that produces libdleyna-renderer and
> libdleyna-server that operating systems can then package as two
> separate packages if they want to.
>
We did consider putting the three libraries together in the same
repository, and for exactly the reasons you mention. In the end we
decided not to. I guess there were a number of reasons for this.
1. It is possible that someone might be interested in dleyna-renderer
and not dleyna-server, e.g., if they just wanted to implement 2-box push
and didn't care about media servers. Alternatively, someone
implementing a DMP would only be interested in dleyna-server. If we
bundle everything together it will be more difficult for people to
determine whether a change to the combined repository affects them ( at
the Github level at least). Note, that the two libraries have the same
dependencies so it's not currently possible to save on dependencies by
excluding one of the libraries. This may of course change in the future.
2. In there future there will probably be more libraries, e.g.,
libdleyna-printer, or libraries to interface with yet undefined DLNA
devices. We were concerned that a combined repository might become very
large going forward and that ultimately we would be obliged to split.
3. We thought it would be easier to manage issues ( again at the github
level ) if we kept things separate.
Now the question we need to ask ourselves is, are these reasons
sufficient for keeping everything separate? Will doing so over
complicate packaging?
Another option we considered was to bundle libdleyna-core,
libdleyna-server and libdleyna-renderer into one repository but keep the
libdleyna-core API public. Libraries for accessing other DLNA devices
would be placed in separate repositories. Ultimately, we decided not to
do this as we felt it would be easier to manage the issues if we keep
everything separate.
Another point that was discussed about how to manage these libraries, is
to use git-submodules.
We decide to not have an official super project, but someone interested
could manage such a thing.
>
>> dleyna-conn-dbus
>> dleyna-linux
>
> To make sure I've understood: dleyna-conn-dbus is one implementation
> of the IPC that the libraries above are going to need, and
> dleyna-linux combines one specific IPC method (D-Bus) and the actual
> libraries. So dleyna-linux provides both D-Bus services but no
> libraries?
>
Pretty much although I think the plan is that the connectors are loaded
dynamically at run time, so dleyna-linux currently doesn't know anything
about them. So dLeyna-linux basically contains some make files and a
small C file with a main loop and some signal handling.
> If I understood this correctly, the same questions probably apply:
> what is the actual benefit of keeping the ipc part of the library
> outside the library (even if the part is going to be interchangable)?
> I would assume it would be simpler to conditionally build only the
> wanted connector than it is to define and maintain a public IPC API
> and an additional project that combines the library/libraries and a
> chosen connector.
>
The idea here was to avoid having a project that gets more and more
complicated as we add new IPC mechanisms. Also there will be IPC
mechanisms that are platform specific such as d-Bus and binder and we
thought bundling them together might get messy. Regardless of how we
organise these connectors, I think we will want to keep the connector
API public to allow 3rd parties to cleanly integrate dLeyna into
platforms that use custom IPC mechanisms.
The notion of "service" is different between various platform, even
linux based.
So when we think about porting dleyna to other platform, we need to port
also the server.
Service in common linux distribution is a 'daemon'.
Service in Android is a binder service.
Service in Windows in another mechanism.
For instance we have the dleyna-linux, plan to port it on Android, so we
will probably have dleyna-android.
And if in the community someone want to port it to windows...
For the same reasons, we decide to make separate repositories to avoid a
lot of complex dependencies in these independent projects.
> By the way, what do you think about just calling them
"ipc" instead of
> "connector" (assuming that's what they are): I think that term will be
> widely understood by most people. It's possible I haven't totally
> understood the whole idea though and a new name makes sense.
Sounds okay to me. Regis, is there a particular reason to stick with
connector?
Sound good to me. I don't have a preference. Maybe "IPC" is clearer.
>
>> Does anybody see any problems or objections with this approach?
>
> I hope I didn't come off as too negative -- that was not the intention
> -- like I said I'm still just jumping around the code trying to make
> sure I even understand what's going on...
> I agree that simplifying the setup would make a lot of sense sense but
> I'm just concerned that adding lots of moving parts (and especially
> APIs that are at least somewhat public) could be a problem later on.
>
Not at all. This is exactly the sort of feedback we need. We only want
to do the re-org once so we need to get it correct. Feel free to
suggest a counter proposal.
>
> Br,
> Jussi
> _______________________________________________
> dLeyna mailing list
> dLeyna(a)lists.01.org
> https://lists.01.org/mailman/listinfo/dleyna
>
_______________________________________________
dLeyna mailing list
dLeyna(a)lists.01.org
https://lists.01.org/mailman/listinfo/dleyna
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
1:22 a.m.
Thanks for you explanations guys, it's very useful for me at least.
On 18 February 2013 14:38, Ludovic Ferrandis
<ludovic.ferrandis(a)intel.com> wrote:
Hi,
On 18/02/2013 13:23, Mark wrote:
>
> Hi Jussi,
>
You was faster to answer :)
> On 02/18/2013 12:03 PM, Jussi Kukkonen wrote:
>>
>> Hi,
>>
>> The reasoning for a change you gave sounds really solid but I do have
>> some questions about this... I'm still just wrapping my head around
>> the whole thing so be prepared for questions that may, or may not,
>> make sense.
>>
>> On 14 February 2013 17:47, Ludovic Ferrandis
>> <ludovic.ferrandis(a)intel.com> wrote:
>>>
>>> So to summarise, we are proposing to split the existing dLeyna code
>>> into the
>>> following repositories:
>>>
>>> dleyna-core
>>> dleyna-renderer
>>> dleyna-server
>>
>>
>> I know you guys must have thought about this but I'm just thinking if
>> the added complexity to developers (having to build multiple libraries
>> and keep them in sync) is worth the benefit -- I assume this means
>> dleyna-core becomes public API which is also additional work for
>> various people. For something like gupnp a smaller grained division
>> makes sense (because there can be developers who do not need all of
>> the libs, and the dependencies of the additional libs can be very big)
>> but is this really true for e.g. dleyna-core?
>>
>> Basically, I'm trying to understand what the benefit is compared to a
>> single dleyna-* repo that produces libdleyna-renderer and
>> libdleyna-server that operating systems can then package as two
>> separate packages if they want to.
>>
>
> We did consider putting the three libraries together in the same
> repository, and for exactly the reasons you mention. In the end we
> decided not to. I guess there were a number of reasons for this.
>
> 1. It is possible that someone might be interested in dleyna-renderer
> and not dleyna-server, e.g., if they just wanted to implement 2-box push
> and didn't care about media servers. Alternatively, someone
> implementing a DMP would only be interested in dleyna-server. If we
> bundle everything together it will be more difficult for people to
> determine whether a change to the combined repository affects them ( at
> the Github level at least). Note, that the two libraries have the same
> dependencies so it's not currently possible to save on dependencies by
> excluding one of the libraries. This may of course change in the future.
>
> 2. In there future there will probably be more libraries, e.g.,
> libdleyna-printer, or libraries to interface with yet undefined DLNA
> devices. We were concerned that a combined repository might become very
> large going forward and that ultimately we would be obliged to split.
>
> 3. We thought it would be easier to manage issues ( again at the github
> level ) if we kept things separate.
>
> Now the question we need to ask ourselves is, are these reasons
> sufficient for keeping everything separate? Will doing so over
> complicate packaging?
>
> Another option we considered was to bundle libdleyna-core,
> libdleyna-server and libdleyna-renderer into one repository but keep the
> libdleyna-core API public. Libraries for accessing other DLNA devices
> would be placed in separate repositories. Ultimately, we decided not to
> do this as we felt it would be easier to manage the issues if we keep
> everything separate.
>
Another point that was discussed about how to manage these libraries, is to
use git-submodules.
I'm not totally sold on submodules, at least for development... Maybe
I've not read the manual properly or something, but there seem to be
too many ways of breaking your work flow with submodules. Michael
commented that it behaves "as one git repo, for those who just want to
consume the code", and that's probably true though.
For developers another option is jhbuild: I actually did that even
with the current layout as I needed dleyna and gupnp versions that are
not available on Debian yet (yay 8 month release freeze!).
We decide to not have an official super project, but someone
interested
could manage such a thing.
>>> dleyna-conn-dbus
>>> dleyna-linux
>>
>> To make sure I've understood: dleyna-conn-dbus is one implementation
>> of the IPC that the libraries above are going to need, and
>> dleyna-linux combines one specific IPC method (D-Bus) and the actual
>> libraries. So dleyna-linux provides both D-Bus services but no
>> libraries?
>>
>
> Pretty much although I think the plan is that the connectors are loaded
> dynamically at run time, so dleyna-linux currently doesn't know anything
> about them. So dLeyna-linux basically contains some make files and a
> small C file with a main loop and some signal handling.
>
>
>> If I understood this correctly, the same questions probably apply:
>> what is the actual benefit of keeping the ipc part of the library
>> outside the library (even if the part is going to be interchangable)?
>> I would assume it would be simpler to conditionally build only the
>> wanted connector than it is to define and maintain a public IPC API
>> and an additional project that combines the library/libraries and a
>> chosen connector.
>>
>
> The idea here was to avoid having a project that gets more and more
> complicated as we add new IPC mechanisms. Also there will be IPC
> mechanisms that are platform specific such as d-Bus and binder and we
> thought bundling them together might get messy. Regardless of how we
> organise these connectors, I think we will want to keep the connector
> API public to allow 3rd parties to cleanly integrate dLeyna into
> platforms that use custom IPC mechanisms.
>
The notion of "service" is different between various platform, even linux
based.
So when we think about porting dleyna to other platform, we need to port
also the server.
Service in common linux distribution is a 'daemon'.
Service in Android is a binder service.
Service in Windows in another mechanism.
For instance we have the dleyna-linux, plan to port it on Android, so we
will probably have dleyna-android.
And if in the community someone want to port it to windows...
For the same reasons, we decide to make separate repositories to avoid a lot
of complex dependencies in these independent projects.
For the connectors, I'm not really sure that is true though: If .e.g
D-Bus is only used in the connector code, it should be fairly straight
forward not to compile that on android, even if code lived in same
repo.
But if out-of-tree IPC mechanisms is a feature that is wanted, then it
does make sense to put all the IPC implementations out-of-tree
(otherwise the feature is never properly tested).
>> By the way, what do you think about just calling them
"ipc" instead of
>> "connector" (assuming that's what they are): I think that term will
be
>> widely understood by most people. It's possible I haven't totally
>> understood the whole idea though and a new name makes sense.
>
>
> Sounds okay to me. Regis, is there a particular reason to stick with
> connector?
>
Sound good to me. I don't have a preference. Maybe "IPC" is clearer.
It's bikeshedding anyway, don't have a problem with "connector" either
:)
Jussi
12:24 a.m.
On Mon, 2013-02-18 at 13:23 +0100, Mark wrote:
3. We thought it would be easier to manage issues ( again at the
github
level ) if we kept things separate.
Because right now, all bug reports go to one "component", as Github
manages bug reports per repo and per pull request.
Now the question we need to ask ourselves is, are these reasons
sufficient for keeping everything separate? Will doing so over
complicate packaging?
I don't think it has to become more complex if a meta git repo with git
submodules is used. That meta git repo would effectively behave the same
as one git repo, for those who just want to consume the code.
ciao Michael
1:02 a.m.
On 18 February 2013 14:23, Mark <mark.d.ryan(a)linux.intel.com> wrote:
Hi Jussi,
On 02/18/2013 12:03 PM, Jussi Kukkonen wrote:
>
> Hi,
>
> The reasoning for a change you gave sounds really solid but I do have
> some questions about this... I'm still just wrapping my head around
> the whole thing so be prepared for questions that may, or may not,
> make sense.
>
> On 14 February 2013 17:47, Ludovic Ferrandis
> <ludovic.ferrandis(a)intel.com> wrote:
>>
>> So to summarise, we are proposing to split the existing dLeyna code into
>> the
>> following repositories:
>>
>> dleyna-core
>> dleyna-renderer
>> dleyna-server
>
>
> I know you guys must have thought about this but I'm just thinking if
> the added complexity to developers (having to build multiple libraries
> and keep them in sync) is worth the benefit -- I assume this means
> dleyna-core becomes public API which is also additional work for
> various people. For something like gupnp a smaller grained division
> makes sense (because there can be developers who do not need all of
> the libs, and the dependencies of the additional libs can be very big)
> but is this really true for e.g. dleyna-core?
>
> Basically, I'm trying to understand what the benefit is compared to a
> single dleyna-* repo that produces libdleyna-renderer and
> libdleyna-server that operating systems can then package as two
> separate packages if they want to.
>
We did consider putting the three libraries together in the same repository,
and for exactly the reasons you mention. In the end we decided not to. I
guess there were a number of reasons for this.
1. It is possible that someone might be interested in dleyna-renderer and
not dleyna-server, e.g., if they just wanted to implement 2-box push and
didn't care about media servers. Alternatively, someone implementing a DMP
would only be interested in dleyna-server. If we bundle everything together
it will be more difficult for people to determine whether a change to the
combined repository affects them ( at the Github level at least). Note,
that the two libraries have the same dependencies so it's not currently
possible to save on dependencies by excluding one of the libraries. This
may of course change in the future.
2. In there future there will probably be more libraries, e.g.,
libdleyna-printer, or libraries to interface with yet undefined DLNA
devices. We were concerned that a combined repository might become very
large going forward and that ultimately we would be obliged to split.
Ah, I missed this idea in Ludos email. I hadn't thought about the fact
that dleyna-core would be useful for other things that may or may not
live outside the main codebase... That does tip the scales.
3. We thought it would be easier to manage issues ( again at the
github
level ) if we kept things separate.
Now the question we need to ask ourselves is, are these reasons sufficient
for keeping everything separate? Will doing so over complicate packaging?
Another option we considered was to bundle libdleyna-core, libdleyna-server
and libdleyna-renderer into one repository but keep the libdleyna-core API
public. Libraries for accessing other DLNA devices would be placed in
separate repositories. Ultimately, we decided not to do this as we felt it
would be easier to manage the issues if we keep everything separate.
Yes, I get the problem now. If dleyna-core is clearly a single
dependency that another project (like dleyna-printer) might be
interested in then the approach with separate repos sounds reasonable.
>
>> dleyna-conn-dbus
>> dleyna-linux
>
>
> To make sure I've understood: dleyna-conn-dbus is one implementation
> of the IPC that the libraries above are going to need, and
> dleyna-linux combines one specific IPC method (D-Bus) and the actual
> libraries. So dleyna-linux provides both D-Bus services but no
> libraries?
>
Pretty much although I think the plan is that the connectors are loaded
dynamically at run time, so dleyna-linux currently doesn't know anything
about them. So dLeyna-linux basically contains some make files and a small
C file with a main loop and some signal handling.
> If I understood this correctly, the same questions probably apply:
> what is the actual benefit of keeping the ipc part of the library
> outside the library (even if the part is going to be interchangable)?
> I would assume it would be simpler to conditionally build only the
> wanted connector than it is to define and maintain a public IPC API
> and an additional project that combines the library/libraries and a
> chosen connector.
>
The idea here was to avoid having a project that gets more and more
complicated as we add new IPC mechanisms. Also there will be IPC mechanisms
that are platform specific such as d-Bus and binder and we thought bundling
them together might get messy. Regardless of how we organise these
connectors, I think we will want to keep the connector API public to allow
3rd parties to cleanly integrate dLeyna into platforms that use custom IPC
mechanisms.
if you think it is possible to make an API that has a chance of being
future-proof (in the sense that new, yet unknown, IPC mechanisms could
be implemented) and more importantly that implementing out-of-tree IPC
mechanisms is something that someone might actually want to do, then
that does make sense. This is an area I've not yet looked at at all so
I'll just take your word for it.
To wrap up: I think my questions were answered. Separating the lower
parts of the stack (core, renderer, server) seems reasonable.
Separating the ipc I'm not quite as convinced about, but you guys have
obviously thought about it and I haven't really: I'll definitely
believe if you say it makes sense.
> By the way, what do you think about just calling them
"ipc" instead of
> "connector" (assuming that's what they are): I think that term will be
> widely understood by most people. It's possible I haven't totally
> understood the whole idea though and a new name makes sense.
Sounds okay to me. Regis, is there a particular reason to stick with
connector?
>
>> Does anybody see any problems or objections with this approach?
>
>
> I hope I didn't come off as too negative -- that was not the intention
> -- like I said I'm still just jumping around the code trying to make
> sure I even understand what's going on...
> I agree that simplifying the setup would make a lot of sense sense but
> I'm just concerned that adding lots of moving parts (and especially
> APIs that are at least somewhat public) could be a problem later on.
>
Not at all. This is exactly the sort of feedback we need. We only want to
do the re-org once so we need to get it correct. Feel free to suggest a
counter proposal.
>
> Br,
> Jussi
> _______________________________________________
> dLeyna mailing list
> dLeyna(a)lists.01.org
> https://lists.01.org/mailman/listinfo/dleyna
>
_______________________________________________
dLeyna mailing list
dLeyna(a)lists.01.org
https://lists.01.org/mailman/listinfo/dleyna
1:20 a.m.
On 18/02/2013 15:02, Jussi Kukkonen wrote:
On 18 February 2013 14:23, Mark <mark.d.ryan(a)linux.intel.com>
wrote:
> Hi Jussi,
>
> On 02/18/2013 12:03 PM, Jussi Kukkonen wrote:
>>
>> Hi,
>>
>> The reasoning for a change you gave sounds really solid but I do have
>> some questions about this... I'm still just wrapping my head around
>> the whole thing so be prepared for questions that may, or may not,
>> make sense.
>>
>> On 14 February 2013 17:47, Ludovic Ferrandis
>> <ludovic.ferrandis(a)intel.com> wrote:
>>>
>>> So to summarise, we are proposing to split the existing dLeyna code into
>>> the
>>> following repositories:
>>>
>>> dleyna-core
>>> dleyna-renderer
>>> dleyna-server
>>
>>
>> I know you guys must have thought about this but I'm just thinking if
>> the added complexity to developers (having to build multiple libraries
>> and keep them in sync) is worth the benefit -- I assume this means
>> dleyna-core becomes public API which is also additional work for
>> various people. For something like gupnp a smaller grained division
>> makes sense (because there can be developers who do not need all of
>> the libs, and the dependencies of the additional libs can be very big)
>> but is this really true for e.g. dleyna-core?
>>
>> Basically, I'm trying to understand what the benefit is compared to a
>> single dleyna-* repo that produces libdleyna-renderer and
>> libdleyna-server that operating systems can then package as two
>> separate packages if they want to.
>>
>
> We did consider putting the three libraries together in the same repository,
> and for exactly the reasons you mention. In the end we decided not to. I
> guess there were a number of reasons for this.
>
> 1. It is possible that someone might be interested in dleyna-renderer and
> not dleyna-server, e.g., if they just wanted to implement 2-box push and
> didn't care about media servers. Alternatively, someone implementing a DMP
> would only be interested in dleyna-server. If we bundle everything together
> it will be more difficult for people to determine whether a change to the
> combined repository affects them ( at the Github level at least). Note,
> that the two libraries have the same dependencies so it's not currently
> possible to save on dependencies by excluding one of the libraries. This
> may of course change in the future.
>
> 2. In there future there will probably be more libraries, e.g.,
> libdleyna-printer, or libraries to interface with yet undefined DLNA
> devices. We were concerned that a combined repository might become very
> large going forward and that ultimately we would be obliged to split.
Ah, I missed this idea in Ludos email. I hadn't thought about the fact
that dleyna-core would be useful for other things that may or may not
live outside the main codebase... That does tip the scales.
> 3. We thought it would be easier to manage issues ( again at the github
> level ) if we kept things separate.
>
> Now the question we need to ask ourselves is, are these reasons sufficient
> for keeping everything separate? Will doing so over complicate packaging?
>
> Another option we considered was to bundle libdleyna-core, libdleyna-server
> and libdleyna-renderer into one repository but keep the libdleyna-core API
> public. Libraries for accessing other DLNA devices would be placed in
> separate repositories. Ultimately, we decided not to do this as we felt it
> would be easier to manage the issues if we keep everything separate.
Yes, I get the problem now. If dleyna-core is clearly a single
dependency that another project (like dleyna-printer) might be
interested in then the approach with separate repos sounds reasonable.
>>
>>> dleyna-conn-dbus
>>> dleyna-linux
>>
>>
>> To make sure I've understood: dleyna-conn-dbus is one implementation
>> of the IPC that the libraries above are going to need, and
>> dleyna-linux combines one specific IPC method (D-Bus) and the actual
>> libraries. So dleyna-linux provides both D-Bus services but no
>> libraries?
>>
>
> Pretty much although I think the plan is that the connectors are loaded
> dynamically at run time, so dleyna-linux currently doesn't know anything
> about them. So dLeyna-linux basically contains some make files and a small
> C file with a main loop and some signal handling.
>
>> If I understood this correctly, the same questions probably apply:
>> what is the actual benefit of keeping the ipc part of the library
>> outside the library (even if the part is going to be interchangable)?
>> I would assume it would be simpler to conditionally build only the
>> wanted connector than it is to define and maintain a public IPC API
>> and an additional project that combines the library/libraries and a
>> chosen connector.
>>
>
> The idea here was to avoid having a project that gets more and more
> complicated as we add new IPC mechanisms. Also there will be IPC mechanisms
> that are platform specific such as d-Bus and binder and we thought bundling
> them together might get messy. Regardless of how we organise these
> connectors, I think we will want to keep the connector API public to allow
> 3rd parties to cleanly integrate dLeyna into platforms that use custom IPC
> mechanisms.
if you think it is possible to make an API that has a chance of being
future-proof (in the sense that new, yet unknown, IPC mechanisms could
be implemented) and more importantly that implementing out-of-tree IPC
mechanisms is something that someone might actually want to do, then
that does make sense. This is an area I've not yet looked at at all so
I'll just take your word for it.
To wrap up: I think my questions were answered. Separating the lower
parts of the stack (core, renderer, server) seems reasonable.
Separating the ipc I'm not quite as convinced about, but you guys have
obviously thought about it and I haven't really: I'll definitely
believe if you say it makes sense.
We have thought about merging server and IPC.
There are specific cases, like Android version, where this applies
perfectly .
We could have a single repo, with the server and the binder plug in.
But there are also some generic plug-ins that could run on any
platforms, like the websocket API.
So to avoid confusion with some projects with a single repo, some with 2
and to keep consistency across all platforms and IPC mechanisms, it was
decided to keep everything in its own repo.
1 lib: 1 repo
1 server: 1 repo
1 IPC: 1 repo
>> By the way, what do you think about just calling them
"ipc" instead of
>> "connector" (assuming that's what they are): I think that term will
be
>> widely understood by most people. It's possible I haven't totally
>> understood the whole idea though and a new name makes sense.
>
>
> Sounds okay to me. Regis, is there a particular reason to stick with
> connector?
>
>
>>
>>> Does anybody see any problems or objections with this approach?
>>
>>
>> I hope I didn't come off as too negative -- that was not the intention
>> -- like I said I'm still just jumping around the code trying to make
>> sure I even understand what's going on...
>> I agree that simplifying the setup would make a lot of sense sense but
>> I'm just concerned that adding lots of moving parts (and especially
>> APIs that are at least somewhat public) could be a problem later on.
>>
>
> Not at all. This is exactly the sort of feedback we need. We only want to
> do the re-org once so we need to get it correct. Feel free to suggest a
> counter proposal.
>
>>
>> Br,
>> Jussi
>> _______________________________________________
>> dLeyna mailing list
>> dLeyna(a)lists.01.org
>> https://lists.01.org/mailman/listinfo/dleyna
>>
>
> _______________________________________________
> dLeyna mailing list
> dLeyna(a)lists.01.org
> https://lists.01.org/mailman/listinfo/dleyna
_______________________________________________
dLeyna mailing list
dLeyna(a)lists.01.org
https://lists.01.org/mailman/listinfo/dleyna
--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
3499
days inactive
3503
days old
7 comments
4 participants
participants (4)
-
Jussi Kukkonen -
Ludovic Ferrandis -
Mark -
Michael Hasselmann