perhaps we should change the title of this thread - or move it to "websockets" REST doesn't seem to make sense anymore...

I am not worried about the display of these values in realtime using a Vue value store (modified by websocket information). I think we could get to 30fps with less than 100ms latency - if the hist3 can pump the info out that fast - and still manage the wifi and the websockets...

Ok - I see. Then the interface will also need to show a folder list (with preview / editing options and perhaps metadata viewer - respective to data type.) Do you also expect / hope to send whitelisted commands via some kind of mock-shell?

Wow - I didn't know that that was one of the deliverables. What do you mean by "etc."? Yes, we can serve from any folder. We would need to investigate the possibility of sym-linking a "DCIM" type of folder, but there isn't any real reason why it shouldn't work.

As far as security is concerned, you are probably right sending and receiving flatbuffers. We don’t want DAEMON to unexpectedly crash.

Here is how we could even serve http with libwebsockets, which would help to do the automatic upgrade to ws:// - it is public domain licensed.

There will be minimum three connections with the client device, perhaps four.

So I have "implemented something" - the frontend for the WebRemote and worked with the team today to design a spec. But I would still like @jatha to show some evidence that suggests that "the camera has plenty of resources". I find this hard to believe (its only a relatively low-powered dual arm!!!) and only benchmarks running during a camera state where it is filming and executing scripts could change my opinion. (Or alternatively, a video of htop screen.)

Of course - usually you have the whole reverse proxy cruft because you don't know who / how many clients you will have. The luxury behind this WebRemote as we are building it is that we will at most have exactly one client, who has "properly" identified itself with a UUID. We don't care about the rest of the universe.

And furthermore, the only purpose for having lighttpd is to serve the initial html/js/css to the WebRemote. After a ws:// connection has been made we can even turn it off. (Technically speaking, we could even just use netcat to serve the folder to the browser.)

Can we get rid of the REST server entirely? I was under the impression that we actually agreed to do websockets...

Working spec document

FYI: This is what we are working on for the specification of the C&C. It is neither finished, nor valid JSON or anything else.

"split the control daemon and rest server" -> that would be the approach with websockets, which I prefer and we are investigating right now.

Great! I take it you mean this flavor of libwebsockets: https://libwebsockets.org/

Here is some information about websockets vs. ajax

That sounds great!

As far as the API goes, I would like to suggest versioning it according to a reference standard that documents the REST call, its expectations and all values. The current state (at T865) is what I would consider to be V0 - because it is not systematically standardised. As soon as everything is "written in stone", I would propose promoting the API to V1.

Andrej, are you tracking this conversation too?

Is there a complete list of all current and valid REST package requests?

Cool - I saw that referenced in the C code, but didn't know how to expect / construct it from the JS.

I totally understand the issue with node running on the box, and is why I suggested the C library for websockets.

Should we make an issue here https://github.com/apertus-open-source-cinema/beta-software/issues about registering the available components and middleware routes in order to match the interface expectations as detailed here:

• One thing to keep in mind is that we should get a confirmation from the camera back to the remote that a particular setting/command was applied successfully.
• Also can we push commands from camera to webremote currently without polling?

I will most definitely also be there this year, and we are planning on running a KinoKabaret Assembly using the KINOÏT Platform. It would be really great to work together and let some hacker-filmmakers get some experience with the AXIOM.

I took the local-storage route for the vue.js version of the interface that I built. Here is the flow:

Legal issues? If you mean JetBrains Webstorm - there aren't any legal issues. The EAP version is their prerelease of their software and it is entirely legal and free to use - without registration. Otherwise I wouldn't have shared it in the VM I built.

Yeah, but I really avoid Microsoft at every level in the stack - and I won't be installing visual studio anything on linux. Webstorm is simply the best because the entire environment is built for the kind of engineering needed by web developers...

I just made you all a VM Snapshot for Oracle VM VirtualBox. It's current state has:

I really didn't want to sound condescending, I hope you don't have that impression. In the future it would be excellent if you would make a normal issue report at github that has:

and pull the repo again - there seem to have been a few files in the dist folder that weren't added to the repo yesterday

ok... what security measures? have you enabled javascript?

FYI - I updated the README at the Git Repo - and found a couple files that weren't included in yesterday's commit.

You will see a blank page if you just open the html file in your browser - but that just won't work, sorry. You need to serve it (like I said in the message.) In fact, after I finished the build process this is what it says:

I hope it is dynamic enough.

Old (535 kb):

I am using this logo for the loading image on the vue.js version of the WebUI. So I fixed it (in my repo) but also forked the repo and created apertus_Logo_Pack_V2.2b.tar.gz with the fixed logo. I just made a pull request from our fork.

Just thought I would point out that the AXIOM logo in the logo pack as provided at github is cropped at the bottom:

i would suggest using vuex to store the "mutations" within the browser - but be careful with the latest NPM - they botched the release and it is chowning system critical folders - essentially bricking the device. It is only a temporary problem though.

Yes, two way is built in and templating is why I suggested it in the first place.

Absolutely. I can look into this while building a git project if you like.

Shall I turn this into a git project with test runner, build instructions and switch out jquery for vue.js?

So, I know that there is no Loomio decision making process here (our 150 person non-profit in Hamburg - the Gängeviertel - tried it too, with results similar to your experience...) but I still need some guidance from the core-team on how I should move forward and contribute. I can build everything I wrote about in the CONTROLLER, INTERFACE and DAEMON sections, but it is a considerable amount of work and will take some careful planning and integration...

Maybe something related:

sorry I meant 403.

These two symbols are good for consumer trust in the project. Having beta-testers testing it around the world and confirming that it doesn't cause problems for them is also a chain of evidence that suggests due-diligence.

Question: I am trying to download this:

@sebastian sorry about the Terminology. (You did although just call it WebGUI and then link to ControlGUI...)

I like some of the ideas over at snickerdoodle - especially their app-connectivity. Maybe there are some good ideas over there too...

Yeah, well of course this is something that the industry wants you to do. Considering the number of Betas out there, maybe just write up a simple declaration for each country where the product has been tested with a super official looking checklist, get it signed by the "tester" and someone from the organization.

I am seeing two different perspectives here, and just would like to have some clarification - or even better some benchmarking stats. For your information I have done work on arduino, raspberries, Olimex a20-SOM / LIME (including custom flashing of the NAND), Banana-pi and the O-Droid C-1 - so I am VERY aware of paying attention to system resources and the tough design decisions that come with that.

Ok - I've noted what you said @jatha - thanks for the info. Can you tell me where to find the spec for the openAPI and Plugin Modules?

I thought I read somewhere that there is a virtual machine image that I should use to spin up development... Maybe I imagined that.

Challenge accepted. Can you point me to a resource for a current VM image?

Then maybe a single long running bash script with a high priority / nice-value running as a main control interface that listens for changes to the fifo and where necessary modifies the fifo / and non-volatile file-store for use on startup for init and conf...

Gotcha.

Exactly. Going further, you could also allow users to opt-in their hardware into something like a "fleet health check" which would be a pathway to send errors / regressions / heat statistics whatever back to HQ for QA...

AND ... you can get rid of the custom C++ code cruft for simple api responses.

if you are already using node.js for socket.io it is perfect because it is a breeze to bind two-way into vue.js...

I have to agree with davidak - and go one further:

The performance for our webapp is excellent - even on mobile. We are using lots of components, routes, icon-fonts, 8 translations and roboto font though. I think for apertus it could be really slim. According to the design mock up you need:

We are using in a framework for vue.js called quasar. With one code base we deliver a single-page website, electron native apps for windows, mac and linux and also use cordova for making android and iOS apps. It may be a bit of overkill for your use-case, but if you plan to deliver for more than just phones, maybe it makes sense to tool up at the beginning. That was our decision - and I can say we do not regret investing some extra time early.

cordova would be a build step to make native apps that run within a "webview" container on a mobile device.

One other thing about the designs you linked to, a website in a browser will pretty much always have the OS chrome and Browser chrome at the top. In landscape mode there is a lot of real-estate that goes away. There's probably a way to do that with html5 fullscreen - but that is a part of the spec that browsers / os's have never really gotten right. It will need some testing and tweaking.

And if this seems like a lot to digest, next week I can set aside an afternoon to help you create the tooling and tune the build process in a separate git repo - then you just need to park the submodule in your main repo and you'll be good to go.

Ok. I would highly recommend taking a look at vue.js - its templating features are exactly what is needed here - it has your "ajax" and data-bindings. It is also very lightweight.

Before I can really answer that, I would need a really quick 3 sentence explanation of EXACTLY when the users see this interface and on what screens - or even better, a link to the spec page.

In my opinion, until the networking stack and sudoers permissions are hardened in the Beta Software package, any exposure to the lighttpd service is really dangerous...

I can definitely recommend some sort of build pipeline tailored to the final delivery platform(s). Gulp is a great start, but there are also other options. Having a node based build system is very comfortable - but setting it up can be a great deal of work.

For reference, here is one approach: https://sites.google.com/site/nxcryptophotography/home