search

christophe-calmejane / Hive

ProAudio, AVnu Alliance Milan compatible, ATDECC (AVDECC) Controller
GNU General Public License v3.0
121 stars 16 forks source link

REST implementation #84

Open elabbing opened 4 years ago

elabbing commented 4 years ago

Goodmornig, I'm looking for a more simple way to deploy AVDECC controller on a TSN-AVB network. Then, I'm thinking about to a server-client system based on REST architecture, where master node has AVDECC controller fuction and acts as web-server to provide info about TSN-AVB network (i.e. numeber and state of listeners/talkers) and allows a bit of stream control, with any user having access to network management by any type of terminal with updated internet browser.

Please, I'd like your opinion about and if you could give some hints. Many thanks Best regards

christophe-calmejane commented 4 years ago

Hi,

That is definately something that we have been discussing over the past months, and would be a nice addition to Hive. I'm currently refactoring a bit the internal code to create a library with the core/models so the UI part is more separate from the engine. Using this library to implement a REST engine is something that would be very useful. I'll soon merge my code (including said library) into the public dev branch

christophe-calmejane commented 4 years ago

I think it should be pretty easy to do once I've merged the internal library:

Should be pretty straightforward :)

elabbing commented 4 years ago

Hello, do you think Microsoft REST sdk is mandatory?

I'm leaning about server-side apps, do you think it is possible usage of L-Acoustics /avdecc library directly by javascript with node.js ?

More, I found audioscience/avdecc-lib At your knowledge, are the same library or other ones?

Thanks a lot Best regards

christophe-calmejane commented 4 years ago

Hi,

No I don’t think it’s mandatory, as I don’t have a strong knowledge about REST. But as I looked at Microsoft API it seems pretty easy to use. A standalone project can indeed be made, directly using la_avdecc libraries but I think it would be more powerful on Hive side as it shall soon offer more advanced features that will be accessible from REST.

Audioscience avdecc implementation is a different projet. I don’t know if their library is Milan compatible yet though.

christophe-calmejane commented 4 years ago

This improvement will require hive modelsLibrary which will come with Milestone 1.3.0

christophe-calmejane commented 4 years ago

A good example to write a PoC using HiveLibraries (soon available):

conradek commented 4 years ago

I am interested in the REST API feature. Any ideas on when a beta will be available?

christophe-calmejane commented 4 years ago

Hi, I don’t have any date yet, but I’ll probably be working on it in the next few weeks.

marcohabeck commented 4 years ago

Are you sure you want to do the work for yourself? Because to develop a REST API you only have to install an HTTP service. Especially since the external access creates numerous conflicts. It's a lot of work and I know what I'm talking about. Because I developed such an AVB controller! This supports all 1722.1 functions and not just audio. All security commands, operations and controls are also supported. The entire 1722.1 was mapped in REST + HATEOS. The API drives itself with HAL. In addition, an advertising server is implemented so that other content can also be delivered by the controller. Simple access control and TLS can also be configured. Database per sqlite is experimentally included. The project is stable, but the API keeps changing in small parts. Because improvements are made from practical experience. I deliberately decided to use an HTML5 and JavaScript interface to expand the functionality of the controller. Think about it carefully with the API! You can integrate my API as an interface and save yourself the work! You can follow the development in the German PA-Forum ;). As I said, the project is executable, stable and can be used on a Raspberry Pi or something else. The current REST Workspace I can set there.

christophe-calmejane commented 4 years ago

Hi sir @marcohabeck, I think you are on the wrong project here.

Hive is not just a 1722.1 controller. It's an advanced Pro Audio controlling application, taking advantage of a 3rdparty implementation of 1722.1. In essence, Hive is offering more advanced features than just a 1722.1 controller (audio specific, you are right, but it's the exact target audience of the app), as well as implementing the pro audio mandatory Milan 1722.1 profile. Hive never pretended to be a full 1722.1 controller, only what is meaningful for where it's used: Pro Audio

The REST API I'll work on is not for 1722.1 but for Hive's features (because this is Hive's project, not a 1722.1 library, which should only offer APIs related to the protocol, we are far higher than the protocol layer here).

Does your 1722.1 stack:

So thanks a lot for the warning, I have a pretty good idea on what's coming when implementing this requested feature, but there is no way I'm switching to another 1722.1 stack like that. Kindly.

marcohabeck commented 4 years ago

I understood this to mean that you also want to implement the 1722.1 with REST. That's why I wanted to point out that there is already a project on this.

It doesn't make sense to integrate this into your project, my controller can be reached via HTTP and a UI can also be implemented via HTML / Javascript.

* Implements Milan 1722.1 profile white paper?

Yes provided.

  • Offers Channel Based Routing? Yes provided.
  • Is able to enumerate macOS input or output streams when you run your code from it directly? I am not using pcap driver. But know what you're getting at. I use Berkeley Packet Filter (BPF). With filtering of the CD bit. Unfortunately this did not work properly with some kernels. But it's on the agenda. It is not intended to run on all machines. It is not a UI application but a service. It is no longer up-to-date to provide your own applications for configuring devices. The users expect a web interface. The advantages are apparent. No software needs to be installed, a browser is enough. This is available for all systems.
  • Handles correctly most of the bugged (bad 1722.1 implementation) pro audio devices out there? Not at all, they are displayed as warnings. Bugs and the 1722.1 library were fixed. Commands that e.g. did not allow a GET method were supplemented by HATEOS with information in the controller so that they could be used. This is exactly the problem, there is no 1722.1 controller that maps all functions. Manufacturers cannot properly test their devices. Avoiding bugs in devices is wrong, it is better to eliminate them.

The aim was to fully implement all functions of the 1722.1. No half-finished things or strange ways. Only then can you integrate Milan or NMOS. This is a private project, I don't have a team and I don't earn any money with it. Not even about selling equipment. I will make this available to everyone as open source, 3 years of work.

You should also use it to test your part. Because there are numerous bugs in Hive. For me, too ;)

That is exactly what @elabbing was looking for!

christophe-calmejane commented 3 years ago

@elabbing @conradek What kind of API level would you like to see for a REST server?

Depending on your needs, maybe it's something to be added to the AVDECC library and not Hive (or both).

conradek commented 3 years ago

Hi @christophe-calmejane,

I think an initial implementation would allow the ability to know what entities are on the network, have the ability to connect and disconnect streams/dynamic mappings, and finally be able to retrieve counter information.

christophe-calmejane commented 3 years ago

Ok, I guess it's easy then (the library already knows how to serialize entities and states to json). I'll take a look as soon as I get a chance to do so.