Web Interface For Motion - Discussion.

The Initial Vision by KennethLavrsen

It is amazing today how Motion - rich with features as it is - is still able to run on a machine taking care of 8 cameras in parallel and still leave enough MIPS and RAM for an Apache to run with PHP/MySQL/Perl and still having bandwidth for you to login with SSH and compile software.

The minute you build on an actual GUI in the sense a Gnome or KDE GUI Motion will become a nice looking elephant in a two room appartment.

The roadmap for Motion with respect to making it more user friendly - because I agree this has become a problem with the current implementation - is this.

Motion will continue to be a server software with no GUI built-in the shape of a KDE (QT) or Gnome GUI frontend.

The configuration will still be possible through configuration files as we know it today.

The XMLRPC remote control interface is in principle as a protocol solid but it has two problems.

• The xmlrpc-c library is without a maintainer for the moment. As gcc versions and other libraries evolve it becomes harder and harder for people to build the xmlrpc-c library.
• The XMLRPC protocol is great for machine to machine control but difficult for the occational amateur newbie that may be able to do a little some simple webpages in HTML and that is it.

The decision I made a while ago is to replace the XMLRPC interface by a HTTP webserver interface.

You can say that the XMLRPC interface today is actually exactly that but the language spoken is XML.

So seen from a CPU load / RAM consumption point of view such a change will not change much. In fact a minimalistic HTTP interface that only allows the client to send simple GET type http requests to Motion and receiving simple HTML pages in return will be very simple to make in plain C and probably be even smaller than the current XMLRPC code.

The advantage of this is that any newbie can now remote control Motion from

• The URL entry line in a browser.
• The command line using wget the same way as using motion-control today
• Letting CGI or PHP pages do it by sending simple GET http messages to Motion and serve back the answers to a browser through an Apache.
• Sending just an empty GET (the url with no parameters) will make Motion return a help text like we know today from motion-control

Once we have this simple interface we can enhance it a little bit.

What would make something more similar to a GUI (but not a real GUI) would be a possibility to contact Motion and both see and change all options using a normal browser.

There are two ways to do this.

• Write a front end in Perl or PHP for Apache and let Apache/Perl/PHP take care of transforming option values to HTML forms and submitted HTML forms to simple http.
• Or letting Motion send http forms directly to a browser and accepting and processing the same form through a http POST method. Or in more human language - You connect your browser to Motion - get a simple form back - set the option values and submit the form.

We have always been able to implement the first method as a related project. The 2nd method letting Motion do it is maybe more user friendly but we have to be careful not implementing a heavy and big monster.

First step to replace the current XMLRPC server by HTTP is something Angel has volunteered to work on and he has started. So it is happening. We need the API defined for this. Here is a topic to write it in: MotionHttpAPI.

Second step - I hope to continue the debate in this topic and on the mailing list.

It is very important that we keep this minimalistic to maintain the current advantage of Motion. It is small, effective and powerful. We should not try to make a Zoneminder 2. Let the Zoneminder guys do what Zoneminder is good at and Motion be what it is good at. In fact the two teams could help each other more with improving the heart of Motion which is image based Motion detection.

Ideas

Edit document and add content to this as you like or simply use the comment feature below

-- KennethLavrsen - 29 Sep 2004
-- Sewa

Discussion.

---

I've attached a piece of code that implements a simple http server allowing GET request. So that could be a nice starting to create the webinterface . I'll go ahead and start integrate it to motion to replace the xmlrpc.

-- AngelCarpintero - 29 Sep 2004

You wanted a discussion....

Before I start let me say that my main concerns are

1. Keeping motion stable
2. Being able to configure motion from PHP or another C program.

I must admit that adding a web server to motion concerns me, especially when it involves coding html forms and processing responses. I agree (almost) entirely with what is said above but I would like to see the Perl/PHP/Apache route explored further and there is another alternative.

Admittedly the web server the motion would need is far less complicated than Apache, but it would add significant size and complexity to the motion code. It would need to provide authentication for password protection, probably be multi-threaded and be very very stable. I feel that if there is any way we can keep this separate from motion it should be explored - especially when we already have a perfectly good web server.

How professional an interface will we have if we are using hard coded HTML to provide the interface? Will we be able to serve customizeable style sheets? What about client side scripts for error checking values prior to submission? Will we need any session handling capability? Motion is a security solution so will we be able to offer secure http communications?

Look at the likes of TWiki and Bugzilla they are feature rich systems but nicely plug into Apache. They therefore inherit all Apache's features like password protection, ecrypted communications ...

I think that users of a system running motion have two fairly distinct roles - most people reading this probably combine both roles. First there is the administrator who sets up the configuration and second there is a viewer that just needs to see recordings, view snapshots etc, So maybe there should be two user interfaces for motion?

Maybe XML-RPC is not the right interface, but it does what motion needs - remote procedure calls. Maybe we could look at SOAP which is similar but more actively supported at present.

An alternative solution would be a standalone program that communicates with motion via its XML-RPC or SOAP interface. I have experince of developing such a program in Java and it was relatively simple. It was served from the server machine using Java Web Start and would run on any platform. It would keep the complexity out of motion and provide a much more feature rich interface than HTTP forms can.

-- MikeLees - 03 Oct 2004

---

I'm not a C programmer, but I think that use only C tcp sockets for send commands/settings and get status in the motion main application is the good way, leaving the interface was developed in any other language for anyone, that's can communicate through sockets to the main application (motion). This mean avoid complexity of the one web server. It's is just an idea from a complete ignorant in C programming.

About this, I extracted a small example from GNU C Library at
http://linux-documentation.com/en/package/glibc/Inet-Example.html :

Internet Socket Example

Here is an example showing how to create and name a socket in the Internet namespace. The newly created socket exists on the machine that the program is running on. Rather than finding and using the machine's Internet address, this example specifies INADDR_ANY as the host address; the system replaces that with the machine's actual address.

     #include <stdio.h>
     #include <stdlib.h>
     #include <sys/socket.h>

     #include <netinet/in.h>
     
     int
     make_socket (uint16_t port)
     {
       int sock;
       struct sockaddr_in name;
     
       /* Create the socket. */
       sock = socket (PF_INET, SOCK_STREAM, 0);
       if (sock < 0)
         {
           perror ("socket");
           exit (EXIT_FAILURE);
         }
     
       /* Give the socket a name. */
       name.sin_family = AF_INET;
       name.sin_port = htons (port);
       name.sin_addr.s_addr = htonl (INADDR_ANY);
       if (bind (sock, (struct sockaddr *) &name, sizeof (name)) < 0)
         {
           perror ("bind");
           exit (EXIT_FAILURE);
         }
     
       return sock;
     }
     

-- MarcoCarvalho - 03 Oct 2004

---

Very good debate. I find your oppinions very valuable and I am very open to your proposals.

Actually we may not be that far apart.

What I see is mainly to replace the current XML-RPC interface by http GET commands. And the replies in a more human interface.

I have noticed that most people do not even bother installing xmlrpc and never gets the nice remote control of Motion.

The current xmlrpc interface has no security. No authentication. If you send it a few wrong characters Motion dies. Only a programmer can find out how to talk to Motion with anything else than motion-control. The only security Motion has on the xmlrpc interface is limitting access to localhost.

I cannot say if SOAP is better. But I do not know SOAP. And I am sure that it is not something I can speak with my browser. I will try and educate myself about SOAP - just in case - You cannot reject something you know nothing about

Talking HTML is easy. You write the API for the GETs so that any beginner can build up a URL and send a command to Motion. Motion answers back with minimalistic webpages. Like one line of text.

This enables two things. - You can use wget as a command line control of Motion. - You can build a PHP interface or perl cgi application running under Apache that controls Motion by sending URLs (http GET commands) and parsing the returned "Webpage".

It is not my idea that the web interace of Motion would be one you could make accessible to the public. We will never be able to secure it the way Apache is secured. The current xmlrpc interface is an invitation to a DOS attack. Just two versions ago you could kill all Motion threads by sending an XMLRPC command with the danish letters "æøå". I believe we fixed that but the old xmlrpc lib still cannot support non-english characters and probably never will unless someone takes over the maintenance. So XMLRPC goes out.

I agree that we should not try to build a mini Apache into Motion.

But I think Motion with a minimalistic webserver will be much more user friendly.

Think about the small printer servers the size of a cigarette pack. You access them by web. All you can do is set maybe 10-20 options. But it is dammed easy to do. I got the idea to replace the xmlrpc by http after setting up two of these and finding it so incredibly easy.

Many people are currently working on PHP interfaces for Motion. Their work will not be in vain. Updating the commands from xmlrpc to simple http URLS and they will all work fine.

-- KennethLavrsen - 04 Oct 2004

---

Marco. Your code is a very basic socket program and if you look at the code Angel uploaded, there is very little difference. Making a socket is not too difficult. But we still need an API and a language to speak that API.

A webserver that can parse very simple URLs is actually something quite simple. And answering back in HTML is a couple of lines of headers and a few lines of text.

Example. Browser sends URL:

http://localhost:8090/action?command=makemovie&thread=2

Motion answers back

HEADERS
<html>
Make movie - thread 2 - completed
</html>

Or something similar. Nothing fancy. But anyone can do it with any browser. Or with wget.

The commands that lists all config parameters could be returned as tables.

-- KennethLavrsen - 04 Oct 2004

---

Well Kenneth, now I understand that webserver, it's like a webserver bundled with Coyote Linux ( more minimalist, I think )for web administration.

I'm Looking at Angel's code, it's sounds good and I think that is a good solution.

Good job

( I Thinking in learn C programming )

-- MarcoCarvalho - 04 Oct 2004

---

Just looked at the SOAP specification for 15 minutes and I already need two Aspirin and two Gaviscon.

Far too complicated - for something that can be made much simpler.

What is great about the HTML commands is that the command and the replies can be read by humans when using a browser.

First step is to get the basics to work. The API should perhaps not need too much URL?something=blabla&anotherthing=blablabla&thirdthing=nothing

Instead we can use a pseudo directory structure.

http://motionhost.mydomain.tld:8080/action/makemovie/2

or

http://motionhost.mydomain.tld:8080/2/action/makemovie

I can imagine that the URL

http://motionhost.mydomain.tld:8080/ makes Motion returns a webpage that gives a short status and lists the threads as links.

<html><body>
Motion version 3.1.20 running 3 threads.
<a href="/0/">All</a>
<a href="/1/">Thread 1</a>
<a href="/2/">Thread 2</a>
<a href="/3/">Thread 3</a>
</body></html>

And clicking thread 1 will give you.

<html><body>
<a href="/1/config/list">List Configuration</a>
<a href="/1/config/get">Get Configuration</a>
<a href="/1/config/set">Set Configuration</a>
<a href="/1/config/write">Write Configuration Files</a>
<a href="/1/action/makemovie">Make movie</a>
<a href="/1/action/snapshot">Snapshot</a>
<a href="/1/action/quit">Quit</a>
<a href="/1/detection/status">Detection Status</a>
<a href="/1/detection/start">Start Detection</a>
<a href="/1/detection/pause">Pause Detection</a>
<a href="/1/track/set">Tracking Set</a>
<a href="/1/track/pan">Tracking Pan</a>
<a href="/1/track/tilt">Tracking Tilt</a>
</body></html>

http://motionhost.mydomain.tld:8080/2/action makes Motion return a webpage that looks like this

<html><body>
<a href="/2/action/makemovie">Make Movie</a>
<a href="/2/action/snapshot">Snapshot</a>
<a href="/2/action/quit">Quit</a>
</body></html>

The most complicated is naturally the config parameters.

http://motionhost.mydomain.tld:8080/2/config/list

Simply lists all parameters - maybe with their current values.

http://motionhost.mydomain.tld:8080/2/config/set/user_text/value

or maybe in this case http://motionhost.mydomain.tld:8080/2/config/set?usertext=value

Getting the config parameter values must be something that gets returned in a simple way.

http://motionhost.mydomain.tld:8080/2/config/get/usertext

returns something like this

<html><body>
Motion thread 2
user_text = "value"
</body></html>

So we get something very simple to use an very simple to code.

The URL commands are easy to use both by a PHP or Perl program. The returned values are easy to parse. Just walk through the returned HTML until you get to the line that starts with Motion. The line after can be parsed as parameter = value.

We can even return it as a table.

<html><body>
Motion thread 2
<table><tr>
<td>user_text</td>
<td>value</td>
</tr></table>
</body></html>

Then the program always knows that the value is everything between the second set of <td> and </td>

-- KennethLavrsen - 04 Oct 2004

---

I don't think returning html is a good idea.... Just returning a text/plain message with the result or requested value would be better. Both in not forcing a representation method and in parseability.

As for the URL I think it would be easy to take the current commands and replace the dots with slashes and seperate the variables with a question mark. Also it makes more sense to keep the threadnr at the end instead of in front of the url:

conf.set(thread=1, option=foo, value=bar)

becomes:

/conf/set?thread=1?option=foo?value=bar

Motion shouldn't become a big webserver serving complete html pages, there are plenty other and better programs for that (and not all as big as apache). Otherwise there will always be a fight between simple and ugly pages and big,bloated and beautifull.

Jeroen

-- JeroenVreeken - 04 Oct 2004

---

I share the Jeroen opinion about the return of the webserver, I think returning a simple comma separated string is more flexible for treatment from any language.

-- MarcoCarvalho - 04 Oct 2004

---

I guess that with the right mime type in the header the "webserver" could return plain text that can still be shown in a browser.

The examples I showed above did not indicate any kind of formatting of the returned HTML either. We can experiment a little with sending plain text back to the different browsers.

It is not the HTML vs text that I am hooked on. It is being able to remote control Motion using a standard browser or wget and being able to send/receive those commands without being an expert in exotic remote control protocols that are designed for much larger scale control than setting or reading a simple number or text string.

And nothing prevents a mix of html and plain text. And it is extremly easy to experiment with both. After all adding a few html tags is just plain text.

What I will never want is Motion to start serving HTML help pages etc. We will let Apache take care of that and encourage people to write nice PHP based front ends that can run on Apache and present nice web GUIs, video streams, snapshots, saved motion images etc etc. Apache/PHP/Perl is much better for this sort of thing. And it keeps Motion nice and small.

(nice to see you on TWiki, Jeroen ).

-- KennethLavrsen - 04 Oct 2004

---

I was forced to fiddle with the xmlrpc interface today. Admittedly, it works just fine in the end. It would have saved some time if I could have spoken to motion using HTTP GET requests.

Also, I do like small, efficient (a.k.a. ugly) html interfaces with forms for configuring blackbox devices. everything else (templating, css) would be overkill for motion.

By the way a Southafrican SMS wholesale provider has given some thought to thei (SMTP, FTP, HTTP, XML,...) APIs. Maybe worth a quick glance at their API docs at e.g. https://www.clickatell.com/products/sms-api/

so in short: looking forward to loosing xmlrpc in the future and some means to use HTTP POST or GET to set stuff. I'd also stick to answers in csv plaintext (+ mime header)

glad to see "detection status" in your note, Kenneth

-- RupertRoeslerSchmidt - 22 Oct 2004

---

A patch topic MotionHttpControl has been created where you can download the first patches of concept code.

-- KennethLavrsen - 09 Dec 2004

---

Keep the html interface minimalist only gets (no posts complicates issues), If the user requires more develop something like MotionConfigToy.

-- RobertH - 06 May 2005

---

I believe than the output format must be automatically selected from the http request.

For example, if the request contains an "Accept" header like this: Accept: application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,*/*;q=0.5 Motion should output HTML code.

If someone writes a GUI for KDE, it can send "Accept: text/plain".

-- UnaiUribarri - 04 Jun 2005

---

I've just read that you are doing exactly the same thing, but using a query parameter. I suppose that I've lost my time. Bad luck!

-- UnaiUribarri - 04 Jun 2005

---

I prefer the URL parameter.

How will any you control what http header is sent from for example php using readfile()?

I prefer that patches are submitted as patch topics where it is clear what they are doing and which base version they are made for. This discussion topic is more for discussing how the feature should work.

-- KennethLavrsen - 05 Jun 2005

Note that this discussion topic ended up in the implementation of MotionHttpAPI.

The patches below are no longer relevant. They are all implemented back in 2004/2005.

-- KennethLavrsen - 07 Mar 2008

---