wooky / zupnp Goto Github PK

Creation of an endpoint with size of 0 bits (i.e. it has no fields) currently fails. Figure out a way around that.

Consider using https://github.com/alexnask/interface.zig.

Currently service description XML files are statically served, and are entirely disconnected from the structures in code. This could be problematic if the two ever diverge. Figure out how to avoid that problem. A couple solutions:

• Generate an XML document from the service's structures and serve that document to clients
• Generate an XML document from the service's structures and compare it to the static file in unit tests only

ZUPnP has began life as a wrapper around the pupnp C library. pupnp has a lot of features that ZUPnP also exposes and tries to wrap in a nicer API. Ultimately, however, pupnp is an old library with an awkward API and leaves a lot to be desired. The long-term goal is to move away from it.

To accomplish the goal, first of all, good and well-maintained HTTP server and XML libraries written in Zig will need to be selected. Without them, this library will continue to depend on pupnp.

Once that has been solved, an implementation of the UPnP protocol in Zig will begin. This will require a strong understanding of UPnP, and therefore a lot of research and time.

Once all of that is done, then the fun begins, and the path towards a version 1.0 opens up.

See pupnp/pupnp#329

MediaServer is doing a lot right now:

• Implements required services, nothing more, nothing less
• Each service implements required actions and, once again, nothing more, nothing less
• ContentDirectory's Browse() automatically does filtering and returning of objects by ID

While that's nice and all, that's not supposed to be the purpose of this library. It should only provide interfaces and let the library user implement the rest as they please. The default implementation should be completely removed out of the src/ sources and placed into a new directory, e.g. supporting/.

Only version 1.14.x is currently supported, but every distro has a different version of libupnp provided, with its own API. Try to support as many versions as possible, at least 1.8.x should do.

How it currently works:

1. PostRequest cookie gets created in open()
2. In each write() method the contents get appended to an ArrayList
3. In the close() method, only then we call the endpoint's post() method with the contents collected from the client

How it should work:

• Do not collect contents from client unless the endpoint specifically wants that
• Add some methods to ServerPostRequest:
  • getChunk() -> ?[]const u8 Get the chunk as passed to the write() method, or null if we're in the close() method
  • getAllContents() -> ![]const u8 Continuously calls getChunk() until all contents are retrieved

What needs to be done:

1. In open(), create PostRequest cookie and ServerPostRequest, then call the endpoint's post() method
2. The method will continue running until it returns, or ServerPostRequest's getChunk() et al gets called, in which case the frame gets suspended
3. Continue to the write() method, and if the endpoint's frame got suspended, resume the frame with the contents from write()'s parameters
4. Execution might continue to another write() method, so repeat step 3
5. Finally, the close() method is reached. If there is still a suspended frame, resume it with null contents, until the frame exits

What's the problem:

• The endpoint's post() function is of unknown size, as it's being dynamically dispatched, so @asyncCall is most likely required
• Need to keep track of how big the frame will need to be
• Try using this library, it might simplify things: https://github.com/alexnask/interface.zig
  • #5 may also use the aforementioned library

Whenever an application using the library gets restarted, it generates new UUIDs for devices. This annoys control points that now report a new device has popped out, while the old device is disconnected and might come back online at some other time (hint: it will never come back). If the same UUID gets generated for the device, everyone will be happier.

One thing to note is that if the library creates multiple devices of the same type (e.g. multiple MediaServers), each one of those needs its own deterministic UUID, so we might need to update the API to have the user provide a name for the device.

Try using the uuid_create_from_name function from https://github.com/pupnp/pupnp/blob/master/upnp/src/uuid/uuid.c#L232. Using any other function from uuid.c is impossible because they're not exported, and therefore not callable.

See section 4.3 of https://www.ietf.org/rfc/rfc4122.txt for assistance.

For best results, fill in the node field of upnp_uuid with the MAC address, however don't expect that to be easy.

For best results, make devices code in src/upnp/device reusable.