The chosen solution is to have only one Github repository. I will ask for the creation of the repo on Github then move our 3 projects in it. We will be able to keep history, but there will be some modifications in the build architecture too. We won't be able to maintain a single Makefile. So we will switch to a sub folder Makefile option. The process will be to: 1 - Create the repo 2 - Import the 3 MSU/RSU/MSD repos 3 - Update the config/Make file to make the 3 components works as previously 4 - Label to v0.0.1 At this stage we will be able to switch to the new repo 5 - Start reorg Ludo On Fri, Dec 14, 2012 at 11:03 AM, Ferrandis, Ludovic < ludovic.ferrandis(a)intel.com&gt; wrote: > Discussion open: <https://github.com/01org/media-service-upnp/issues/156> > > *Summary:* > > We have currently 3 components, MSU, RSU and Media-Service-Deo (MSD) > > To optimize code, to make dLeyna more modular and as much as possible > techo independent (like dbus) or easily integrated in other techo (like > websocket) we need to reorganize the source. > > In the same time, we are going to rename the components as > media-service-upnp or renderer-service-upnp are not really relevant. > > The project should be split in various components described below: > > - dleyna-core (The dLeyna common library) > - dleyna-server (Current MSU libray, without dbus) > - dleyna-renderer (Current RSU, without dbus) > - dleyna-dbus-server (dbus dameon that publish the dbus interface and > rely on dleyna-server) > - dleyna-dbus-renderer (dbus dameon that publish the dbus interface > and rely on dleyna-renderer) > - dleyna-demo (We could add various applications in sub-folders, DMP, > DMC). > > In near future, see other TODO: > > - dleyna-websocket-server > - dleyna-websocket-renderer > > We have 2 choices to implement this architecture change. > > 1 - Create a single *dleyna* repository on github and then each library > will be manged in a sub folder > 2 - Create a github repository by library > > > -- > Ludovic Ferrandis > Open Source Technology Center > > --------------------------------------------------------------------- > Intel Corporation SAS (French simplified joint stock company) > Registered headquarters: "Les Montalets"- 2, rue de Paris, > 92196 Meudon Cedex, France > Registration Number: 302 456 199 R.C.S. NANTERRE > Capital: 4,572,000 Euros > > > -- Ludovic Ferrandis Open Source Technology Center --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros

Hi Ludo,**** ** ** I think this is a good starting point, thanks!**** ** ** However, I think that we probably won’t need 2 separate components for dbus/server and dbus/renderer.**** Also I would like to propose the following architecture (and naming) for the various IPC implementations:**** ** ** connectors/**** connectors/dbus**** connectors/websocket**** connectors/binder**** ** ** ** ** Regis**** ** ** ** ** *From:* dleyna-bounces(a)lists.01.org [mailto:dleyna-bounces@lists.01.org] *On Behalf Of *Ferrandis, Ludovic *Sent:* Thursday, January 17, 2013 12:08 PM *To:* dleyna(a)lists.01.org *Subject:* Re: [dLeyna] Re-Arch: Rename and split components**** ** ** Hi,**** it's time to start.**** So we are going to move all works to our new dleyna repository.**** I won't describe all the work to be done, just the result we're expecting. **** In the dleyna repository:**** |-------------------------------------------------------------------| | Folder name | Composant Name | Function prefix| |-------------------------------------------------------------------|**** | core | dleyna-core | dlc_ |**** | server | dleyna-server | dls_ |**** | renderer | dleyna-renderer | dlr_ | |-------------------------------------------------------------------|**** | dbus/ | | |**** | dbus/server | dleyna-dbus-server | dds_ |**** | dbus/renderer | dleyna-dbus-renderer | ddr_ | |-------------------------------------------------------------------|**** | websocket/ | | |**** | binder/ | | |**** |-------------------------------------------------------------------|**** | demo/ | | |**** | demo/dmc | dleyna-dmc | |**** | demo/dmp | dleyna-dmp | | |-------------------------------------------------------------------|**** | tests/ | | |**** | tests/console/dbus/ | dleyna-server-console | | | | dleyna-renderer-console | |**** | tests/ut/ | | | |-------------------------------------------------------------------|**** Any comments or suggestions about name or organization?**** Ludo**** ** ** ** ** ** ** On Mon, Jan 7, 2013 at 3:47 PM, Ferrandis, Ludovic < ludovic.ferrandis(a)intel.com&gt; wrote:**** The chosen solution is to have only one Github repository.**** I will ask for the creation of the repo on Github then move our 3 projects in it.**** We will be able to keep history, but there will be some modifications in the build architecture too. We won't be able to maintain a single Makefile. So we will switch to a sub folder Makefile option.**** The process will be to:**** 1 - Create the repo**** 2 - Import the 3 MSU/RSU/MSD repos**** 3 - Update the config/Make file to make the 3 components works as previously**** 4 - Label to v0.0.1**** At this stage we will be able to switch to the new repo**** 5 - Start reorg**** Ludo**** **** ** ** ** ** On Fri, Dec 14, 2012 at 11:03 AM, Ferrandis, Ludovic < ludovic.ferrandis(a)intel.com&gt; wrote:**** Discussion open: <https://github.com/01org/media-service-upnp/issues/156> *Summary:***** We have currently 3 components, MSU, RSU and Media-Service-Deo (MSD)**** To optimize code, to make dLeyna more modular and as much as possible techo independent (like dbus) or easily integrated in other techo (like websocket) we need to reorganize the source.**** In the same time, we are going to rename the components as media-service-upnp or renderer-service-upnp are not really relevant.**** The project should be split in various components described below:**** - dleyna-core (The dLeyna common library)**** - dleyna-server (Current MSU libray, without dbus)**** - dleyna-renderer (Current RSU, without dbus)**** - dleyna-dbus-server (dbus dameon that publish the dbus interface and rely on dleyna-server)**** - dleyna-dbus-renderer (dbus dameon that publish the dbus interface and rely on dleyna-renderer)**** - dleyna-demo (We could add various applications in sub-folders, DMP, DMC).**** In near future, see other TODO:**** - dleyna-websocket-server**** - dleyna-websocket-renderer**** We have 2 choices to implement this architecture change.**** 1 - Create a single *dleyna* repository on github and then each library will be manged in a sub folder 2 - Create a github repository by library**** -- **** Ludovic Ferrandis**** Open Source Technology Center**** --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros**** ** ** -- **** Ludovic Ferrandis**** Open Source Technology Center**** --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros**** -- **** Ludovic Ferrandis**** Open Source Technology Center**** --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros**** --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

| connectors/ | |

| connectors/dbus | dleyna-connector-dbus | dcd_

| connectors/websocket/ | dleyna-connector-websocket | dcw_

| connectors/binder/ | dleyna-connector-binder | dcb_

Good point. Also, I guess one service will want to be able to support multiple IPC mechanisms at the same time. For example, we will probably want to have a dleyna-dms-cp service that supports both d-Bus and websockets.

What if the connector is a shared lib loaded at runtime depending on a setting in a config file ? (looking at rygel's media engines for instance) This way we don't have to have different binaries (and names!) for the server or the renderer.

Hi Regis, On Thu, 2013-01-17 at 15:25 +0000, Merlino, Regis wrote: > > Good point. Also, I guess one service will want to be able to support multiple IPC mechanisms at the same time. For example, we will probably want to have a dleyna-dms-cp service that supports both d-Bus and websockets. > > I was not going that far with my proposal, but yes, you're right, I don't see any blocking issue in supporting several IPC mechanism at the same time and then having a single daemon running :-) > So, yep, I follow you in the idea of having a single generic process, good idea. > Just to be clear I was suggesting two generic processes, dleyna-dms-cp and dleyna-dmr-cp. Both of these would be capable of loading multiple connectors. Mark > Regis > > > -----Original Message----- > From: dleyna-bounces(a)lists.01.org [mailto:dleyna-bounces@lists.01.org] On Behalf Of Mark D Ryan > Sent: Thursday, January 17, 2013 4:09 PM > To: dleyna(a)lists.01.org > Subject: Re: [dLeyna] Re-Arch: Rename and split components > > Hi Regis, > > On Thu, 2013-01-17 at 14:58 +0000, Merlino, Regis wrote: > > What if the connector is a shared lib loaded at runtime depending on a > > setting in a config file ? (looking at rygel's media engines for instance) This way we don't have to have different binaries (and names!) for the server or the renderer. > > > > Good point. Also, I guess one service will want to be able to support multiple IPC mechanisms at the same time. For example, we will probably want to have a dleyna-dms-cp service that supports both d-Bus and websockets. > > So we could create one generic process for the renderer and one for the server that load connectors as required by the user. If someone does not want to use this plugin mechanism they are free to create their own service processes that link at compile time against the corelibs and the connectors that they need. > > Regards, > > Mark > > > > > _______________________________________________ > 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

Hi Ludo, Apologies for my late reply. On Thu, 2013-01-17 at 16:53 +0100, Ferrandis, Ludovic wrote: > dleyna-server is the generic server that will load the connectors. > > > To simplify and also to be more crash proof, each connector should be > run in its own process (dleyna-server fork itself for each connector > it load) > > > For each connector, we have 3 solutions: > > 1 - One connector manage both dms & dmr (or only one, decided at > compile time) > > 2 - Under each connector (dbus for ex), we have in fact 2 connectors, > one for dms, one for dmr. > > 3 - -- I don't like it -- One connector that fork itself so we have > one servce for dms/dmr > > > Personally, I prefer the first solution because: 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.

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.

If we wanted to provide access to DMSs and DMRs through a different IPC mechanism, e.g., websockets, a separate service would be run.

Is this correct?

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. not just dbus I hope... :=) Has anyone invented a name for the dbus/binder/whatever abstractions?

Hi Regis, On Thu, 2013-01-17 at 14:58 +0000, Merlino, Regis wrote: > What if the connector is a shared lib loaded at runtime depending on a setting in a config file ? (looking at rygel's media engines for instance) > This way we don't have to have different binaries (and names!) for the server or the renderer. > Good point. Also, I guess one service will want to be able to support multiple IPC mechanisms at the same time. For example, we will probably want to have a dleyna-dms-cp service that supports both d-Bus and websockets. So we could create one generic process for the renderer and one for the server that load connectors as required by the user. If someone does not want to use this plugin mechanism they are free to create their own service processes that link at compile time against the corelibs and the connectors that they need. Regards, Mark _______________________________________________ dLeyna mailing list dLeyna(a)lists.01.org https://lists.01.org/mailman/listinfo/dleyna

Hi Ludo, On Thu, 2013-01-17 at 15:01 +0100, Ferrandis, Ludovic wrote: Update based on Regis comments |-----------------------------------------------------------------------| > > | connectors/ | | | > | connectors/dbus | dleyna-connector-dbus | dcd_ | > | connectors/websocket/ | dleyna-connector-websocket | dcw_ | > | connectors/binder/ | dleyna-connector-binder | dcb_ | > |-----------------------------------------------------------------------| > I think we're still missing something here. If I understand correctly core, server and renderer are all libraries. The code under connectors are libraries as well. So we also need some components that combine the core libraries and a connector to make a service. Also, perhaps we should move core, server and renderer under a separate directory, to be consistent with connectors, demos and tests. Not sure what to call this really, perhaps corelibs? Do we want to prefix our libraries with lib, e.g., libdleyna-core? Finally, might dleyna-server and dleyna-renderer be confusing for some people as they might give the impression that they implement servers and renderers when in fact that implement control points that access servers and renderers. What about libdleyna-dms-cp and libdleyna-dmr-cp? Our services might then be called dleyna-dms-cp-dbus and dleyna-dmr-cp-dbus. If that's too many hyphens we could go with dleyna-dmscp-dbus instead. Regards, Mark _______________________________________________ dLeyna mailing list dLeyna(a)lists.01.org https://lists.01.org/mailman/listinfo/dleyna

Hi, it's time to start. So we are going to move all works to our new dleyna repository. I won't describe all the work to be done, just the result we're expecting. In the dleyna repository: |-------------------------------------------------------------------| | Folder name | Composant Name | Function prefix| |-------------------------------------------------------------------| | core | dleyna-core | dlc_ | | server | dleyna-server | dls_ | | renderer | dleyna-renderer | dlr_ | |-------------------------------------------------------------------| | dbus/ | | | | dbus/server | dleyna-dbus-server | dds_ | | dbus/renderer | dleyna-dbus-renderer | ddr_ | |-------------------------------------------------------------------| | websocket/ | | | | binder/ | | | |-------------------------------------------------------------------| | demo/ | | | | demo/dmc | dleyna-dmc | | | demo/dmp | dleyna-dmp | | |-------------------------------------------------------------------| | tests/ | | | | tests/console/dbus/ | dleyna-server-console | | | | dleyna-renderer-console | | | tests/ut/ | | | |-------------------------------------------------------------------| Any comments or suggestions about name or organization? Ludo On Mon, Jan 7, 2013 at 3:47 PM, Ferrandis, Ludovic < ludovic.ferrandis(a)intel.com&gt; wrote: > The chosen solution is to have only one Github repository. > > I will ask for the creation of the repo on Github then move our 3 > projects in it. > > We will be able to keep history, but there will be some modifications in > the build architecture too. We won't be able to maintain a single Makefile. > So we will switch to a sub folder Makefile option. > > The process will be to: > > 1 - Create the repo > 2 - Import the 3 MSU/RSU/MSD repos > 3 - Update the config/Make file to make the 3 components works as > previously > 4 - Label to v0.0.1 > > At this stage we will be able to switch to the new repo > > 5 - Start reorg > > Ludo > > > > > > > > On Fri, Dec 14, 2012 at 11:03 AM, Ferrandis, Ludovic < > ludovic.ferrandis(a)intel.com&gt; wrote: > >> Discussion open: <https://github.com/01org/media-service-upnp/issues/156 >> > >> >> *Summary:* >> >> We have currently 3 components, MSU, RSU and Media-Service-Deo (MSD) >> >> To optimize code, to make dLeyna more modular and as much as possible >> techo independent (like dbus) or easily integrated in other techo (like >> websocket) we need to reorganize the source. >> >> In the same time, we are going to rename the components as >> media-service-upnp or renderer-service-upnp are not really relevant. >> >> The project should be split in various components described below: >> >> - dleyna-core (The dLeyna common library) >> - dleyna-server (Current MSU libray, without dbus) >> - dleyna-renderer (Current RSU, without dbus) >> - dleyna-dbus-server (dbus dameon that publish the dbus interface >> and rely on dleyna-server) >> - dleyna-dbus-renderer (dbus dameon that publish the dbus interface >> and rely on dleyna-renderer) >> - dleyna-demo (We could add various applications in sub-folders, >> DMP, DMC). >> >> In near future, see other TODO: >> >> - dleyna-websocket-server >> - dleyna-websocket-renderer >> >> We have 2 choices to implement this architecture change. >> >> 1 - Create a single *dleyna* repository on github and then each library >> will be manged in a sub folder >> 2 - Create a github repository by library >> >> >> -- >> Ludovic Ferrandis >> Open Source Technology Center >> >> --------------------------------------------------------------------- >> Intel Corporation SAS (French simplified joint stock company) >> Registered headquarters: "Les Montalets"- 2, rue de Paris, >> 92196 Meudon Cedex, France >> Registration Number: 302 456 199 R.C.S. NANTERRE >> Capital: 4,572,000 Euros >> >> >> > > > -- > Ludovic Ferrandis > Open Source Technology Center > > --------------------------------------------------------------------- > Intel Corporation SAS (French simplified joint stock company) > Registered headquarters: "Les Montalets"- 2, rue de Paris, > 92196 Meudon Cedex, France > Registration Number: 302 456 199 R.C.S. NANTERRE > Capital: 4,572,000 Euros > > -- Ludovic Ferrandis Open Source Technology Center --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros _______________________________________________ dLeyna mailing list dLeyna(a)lists.01.org https://lists.01.org/mailman/listinfo/dleyna