SSDP covers discovery of the services and how they are set up; SOAP and XML are then used to access the service. IANAE, but; I think as long as you restrict yourself to implement use of the particular service (IGD) you are interested in, it shouldn't be all that bad; the use of SSDP discovery data should be fairly straigh forward the way its modelled; you provide the client with callbacks that run when a service of the type you've specified you're interested in becomes available/unavailable.
The main problem with UPnP (well, other than accessing services involving SOAP and XML instead of REST) is its size; a callback handling "IGD service discovered" should be much simpler than if one wanted to handle "UPnP device discovered" (or, if that's the pattern, restricting UPnP device discovery handling to check if IGD is available). (You might want a separate Service subclass to ease access / document what the different fields are though, IIRC, the current Service follows the MorphicExtension pattern of putting anything that does not have a well-defined meaning in SSDP in a dictionary) Cheers, Henry > On 25 Jul 2016, at 3:29 , Norbert Hartl <norb...@hartl.name> wrote: > > Thanks, > > am I wrong in assuming the UPnP and IGD are rather huge and complicated > things to implement? I just want to figure out if there is a clear answer to > the question if implementing a subset or using a library (mini upnp) through > FFI is more feasible. > > Norbert >> Am 25.07.2016 um 16:10 schrieb Henrik Johansen >> <henrik.s.johan...@veloxit.no>: >> >> >>> On 25 Jul 2016, at 12:13 , Norbert Hartl <norb...@hartl.name> wrote: >>> >>> Does anyone know some code or person that did something with UPnP/IGD in >>> pharo? >>> >>> thanks, >>> >>> Norbert >> >> >> I've done an SSDP client/server, but not gone so far as to build a full UPnP >> model on top of it, since I just needed a discovery protocol. >> http://smalltalkhub.com/#!/~henriksp/SSDP. >> >> Should be possible to use as a base though; you can make a client with type >> ssdp:all, and get some fun replies indicating the services available on UPnP >> routers. >> >> Caveats apply to the socket init code which is really ugly, it attempts to >> listen on all the interfaces present at the time of client creation, but the >> correct primitives aren't really exposed from the plugin, the results can be >> a bit hit and miss depending on OS/Distribution; nor are there hooks to get >> notified when interfaces go up/down, so accounting for such currently comes >> down to manual resets. >> >> Cheers, >> Henry > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
