Support for multiple devices per server

[dearchap]

Right now we can add multiple services to root device. However some emulated devices actually consist of services as well as multiple sub-devices(each with its own services). Can the upnpserver code be moved into a device class in device.js ? That way upnpserver can be given just the root device node and internally it can create services and sub-devices etc.

[s-leger]

Hi,
This is what the device branch is about.
Allow multiple devices on a single host. (sharing one single ssdp server)
But at this time every device is a root device with his own services.
I’ll take a look at the possibility of having a single root device with sub devices.

Le 1 sept. 2015 à 21:16, dearchap notifications@github.com a écrit :

Right now we can add multiple services to root device. However some emulated devices actually consist of services as well as multiple sub-devices(each with its own services). Can the upnpserver code be moved into a device class in device.js ? That way upnpserver can be given just the root device node and internally it can create services and sub-devices etc.

—
Reply to this email directly or view it on GitHub #37.

[dearchap]

Where is the "device" branch ? I dont see it in the list of branches.

[s-leger]

Sorry, at this time i'ts on
https://github.com/s-leger/upnpserver/tree/device
Still work in progress

[s-leger]

pushed branch here
https://github.com/oeuillot/upnpserver/tree/device

Olivier realy do a great work with his api, and it's a strong starting point to implement other devices / services.
This branch focus on device abstraction, taking MediaServer out from upnpServer.
MediaRender is far from being working as it, but is a good test case for the Device abstraction.
AVTransport still need some care.
RenderingControl still missing.

Configuration sample

• service names are file names without "Service"
• device names are file names
• configuration for services is done through an object under serviceName key (see contentDirectory)

The server start automagically no need to call any method

  var UpnpAPI = require("upnpserver").UpnpAPI;

  var server = new UpnpAPI({
    ssdp:{
      Log:0,
      LogLevel:"error"
    },
    // Rootdevices are objects in root array
    root:[{     // this device has one main MediaRender and a embed MediaServer device
       lang:'fr',
       httpPort:8080,
       dlna:true,
       devices:{
        MediaRender:{
          uuid:"A00C5515-23AA-43EC-BA7F-659603492942",
          player:"Player",
          services:{
            connectionManager:"",
            avTransport:"",
            renderingControl:""
          }
        },
        MediaServer:{
          dlna:1 ,
          microsoft:0,
          uuid:"A00C5515-23AA-43EC-BA7F-659603492941",
          enableIntelToolkitSupport:false,
          services:{
            connectionManager:"",
            mediaReceiverRegistrar:"",
            contentDirectory:{
              paths:[
                { path: '/Users/stephen/Documents', mountPoint: '/Documents' }
              , { mountPoint:'/IceCast', type:'icecast'}
              //, { mountPoint: '/Audio', type:'music', path:'/Users/stephen/Music'}
              //, { mountPoint: '/Video', type:'path', path:'/Users/stephen/Movies'}
              //, { mountPoint: '/Images', type:'path', path:'/Users/stephen/Pictures'}
              ]
            }
          }
        }
        }
      },{           // this device has one main MediaServer device
       devices:{
        MediaServer:{
          name:"MS",
          dlna:1 ,
          microsoft:0,
          uuid:"A00C5515-23AA-43EC-BA7F-659603492946",
          enableIntelToolkitSupport:false,
          services:{
            connectionManager:"",
            mediaReceiverRegistrar:"",
            contentDirectory:{
              paths:[
                { path: '/Users/stephen/Documents', mountPoint: '/Documents' }
              , { mountPoint:'/IceCast', type:'icecast'}
              //, { mountPoint: '/Audio', type:'music', path:'/Users/stephen/Music'}
              //, { mountPoint: '/Video', type:'path', path:'/Users/stephen/Movies'}
              //, { mountPoint: '/Images', type:'path', path:'/Users/stephen/Pictures'}
              ]
            }
          }
        }
        }
      },{         // this device has one main MediaRender device
       devices:{
        MediaRender:{
          name:"MR",
          uuid:"A00C5515-23AA-43EC-BA7F-659603492948",
          player:"Player",
          services:{
            connectionManager:"",
            avTransport:"",
            renderingControl:""
          }
        }
       }
    }]
  });
  server.on("error", console.log);

[dearchap]

I was thinking that we can move devices into a separate lib/devices dir and services into lib/services. Shall I make that change ?

[s-leger]

Good idea,
note: take care of contentDirectory dependency they are a lot (mostly auto-required).
Commited my last changes so you can do it.

[oeuillot]

Yes it can be interesting :-)

However, I propose to wait the merge of "device" branch into the master,
and fix some problems if any.
And after, we (you :-) ? ) can work on the separation of devices and
services in different folders !?

@s-leger : an opinion ?

2015-09-02 17:00 GMT+02:00 dearchap notifications@github.com:

I was thinking that we can move devices into a separate lib/devices dir
and services into lib/services. Shall I make that change ?

—
Reply to this email directly or view it on GitHub
#37 (comment).

[s-leger]

It's a bit early to merge. MediaServer still working, but i'll check service / device implementation to ensure we are on the right path. Working on MediaRender is a good test case.
There is also some breaking changes (configuration and API) requiring some care in the command line extension.
We should take some time to think about a good structure for the whole, as there are many deps.

[s-leger]

@oeuillot

• didl-lite fragments and xml as values in soap / GENA responses in general should be xml escaped strings (and unescaped when required). Any idea on how to do it in an efficient way ?
• Filter and xmlns result in many messages about missing standards prefixes upnp, dc.. should we realy only rely on the xmlns of the Filter node ?

[dearchap]

I would think that the lib directory should have just device.js, service.js, ssdp.js, rest should go into utils or other dirs. I've just submitted a pull request for basic dir change

[s-leger]

There is a clear need for a bit more structure. (as we are talking about many devices and services now)
Services deps may reside into folders under lib as upnp classes, repositories ...
Maybe we do have to change contentdirectory related deps found in lib into a sub dir.
Always keep in mind that repo depth could be a nightmare when including files.
A good looking structure worth nothing if at the end of the day you end up with require ../../../serviceXX/serviceXX
Keeping all services and devices implementation under lib seem a good idea, to prevent the require hell.
Even if we end up with say 5 devices and 10 services this is far from being not manageable.

About your first post : the device class may be splitted into Rootdevice handling httpserver and routing requests, and Subdevice handling device configuration and init, in a way we can implement any valid upnp device architecture on a single host.

• single/multiple root with single/multiple sub devices.
  I'll have a look at ssdp server to allow single root with multiple sub devices.

[s-leger]

For services, file naming convention may allow to put all deps into a single folder ensuring auto required files always work.
Also a naming convention for those folders should be a good starting point (service filename prefix).

[dearchap]

My main motivation for using upnpserver is to model a Sonos Zone Player. From its device description I see that it has around 10 services(not including ContentManager, etc) and 2 sub-devices. My initial thought was that upnpserver can have configured with a different "personality" for such use cases using plugins and such. Thats what led me to propose the devices,services directory. However I am open to any mechanism that makes development and structure easy to understand.

[s-leger]

Look realy promising !
I'm planning to achieve an airtunes zone player (allready have one running here, but based on less stronger implementation)

Started a basic implementation of a Player abstraction class to extend and plug into MediaRender, automagically getting events like play, volume.. from services.

Should take a look at a common way to handle multiple instances of services creation on the fly, or via configuration (basic instance creation, destroy and routing allready here).

Currently, i'm thinking about a far stronger abstraction on soap requests/response (using generic actions in/out params handling for any action) making implementation mutch easyer for all soap actions.

[dearchap]

So shall I revert back my services, devices dir changes ? I can just use the current mechanism. Instead of thinking of abstracting out everything right away perhaps I can make my changes in my forked version and then we can figure out how to abstract over time. The challenge then would be the merge if the forks are very far apart.