Remove web interface and api. Updated readme.

[Fensterbank]

This pull request removes the web interface, api and the demo samples from node-dmx-library repository. The code and dependencies are changed in a way that only serialport is used, since all other dependencies were related to the web interface.

While the npm package was not published from this branch, the contents of it should be the same as the already released package, except for a few configuration files.

[wiedi]

I'd like this repository to keep the name "node-dmx" and the npm package name of "dmx". I'll give you permission to publish packages there.

I also think the files demo.js and demo_simple.js are a good fit for the library package. We could move those into an example/ subfolder or something, but having examples on API usage is often helpful.

Maybe we should mention in the readme that the webinterface has been moved to a seperate repository (with a link) - at least for some time.

[Fensterbank]

I'd like this repository to keep the name "node-dmx" and the npm package name of "dmx". I'll give you permission to publish packages there.

@wiedi I still don't see, how that's possible. Only organizational npm accounts have a permission management and support multiple contributers, and organizational npm accounts must be scoped. But I'm not a specialist in npm, it's just what I read about.

A package name like @node-dmx/dmx would be possible. I changed the repository name, so we don't have a repository node-dmx in the organization node-dmx, which looks unusual. But also I'm not really happy with node-dmx-library too, so... ;)

If the package name is dmx (or @node-dmx/dmx), would it make sense to just name the repository dmx? So the repository name would equal the package name.

I also think the files demo.js and demo_simple.js are a good fit for the library package. We could move those into an example/ subfolder or something, but having examples on API usage is often helpful.

You are talking about API usage, but people who want to use the library, should not clone the libary repository and paste their code somewhere. If they have the code of the library, they want to change the library, but not use it in their own tool. Since there is a package on npm, it would make much more sense to have a demo or sample repository which uses dmx as dependency (like the web repository which uses the library). If the demos are part of this library repository, the demos would have other imports than like everybody would need if the library is installed by npm. With a samples repository which uses the library, our users could easily copy, paste & change the code in their own projects, this would not be the case if we have just some demo files in the library itself.

[wiedi]

@wiedi I still don't see, how that's possible. Only organizational npm accounts have a permission management and support multiple contributers, and organizational npm accounts must be scoped.

A NPM package can have multiple maintainers. I've added you to the list.

If the package name is dmx (or @node-dmx/dmx), would it make sense to just name the repository dmx? So the repository name would equal the package name.

I think in the beginning of node.js it was a common practice to have repositories named "node-x" and the package just "x". I'm fine with the repository just being called "dmx".

I'd suggest the webinterface should then become also just "dmx-web" - for both the package and the repository.

I also think the files demo.js and demo_simple.js are a good fit for the library package. We could move those into an example/ subfolder or something, but having examples on API usage is often helpful.

You are talking about API usage, but people who want to use the library, should not clone the libary repository and paste their code somewhere. If they have the code of the library, they want to change the library, but not use it in their own tool.

I agree that API users should not have to paste code into the repository. But e.g. browsing the source on github and having examples in the same place is very valuable.

Also when changing the API the examples, just like tests, can be changed at the same time. This makes it clear to API consumers how the changes impacts them.

If the demos are part of this library repository, the demos would have other imports than like everybody would need if the library is installed by npm.

That's a very good point. It would be good for the examples to have the same imports one would normally use. Maybe there is a way to have that - @bluemaex do you know?

[Fensterbank]

I'm fine with the repository just being called "dmx".

I'd suggest the webinterface should then become also just "dmx-web" - for both the package and the repository.

I agree and changed them. That's indeed the best approach.

It would be good for the examples to have the same imports one would normally use.

This would only be achievable if dmx is installed in the node-modules folder, so that the library is a dependency of the library. I don't think this is possible.

An in fact I still think holding demos and documentation in the library repository is a bad approach. ;) I don't know another project which is doing this, most of them have a specific docs repository. We could easily link from the readme.md to the demos repository and everyone could just clone the demos repository, play around and it would work out of the box without confusing the user with library code.

But if we would merge this, there would be no demo code at all in our repositories, so lets keep the demo.js and demo_simple.js as suggested. I'm currently preparing a new demo project with different samples (some demo animations I used at the chaos congress) and as soon as this thing is ready, we can add it as repository and discuss about the removal of the demo files from this repository again.

If there are no other objections, we would be ready to merge.