HTTP Interface for Motion

Introduction

This document is a first proposal and not at all complete for a http interface to control motion , it will replace xmlrpc in motion 3.2.x.

Discussion

WebInterfaceForMotionDiscussion talking about how should be implemented Http Interface for motion.

API

MotionHttpAPI Describes how works Http Interface , explainig how to get/set values and all the actions and features that it supports.

TODO

• write action. [done]
• Improve track (set , auto , status ). [done]
• Check types of values and ranges.
• Better error handlers. [in progress]
• Avoid race condictions in motion_loop() with cnt.conf.* values.
• Security access ( Basic-Auth ). [done]
• Restrict some parameters for set ( i.ex set?onsave=rm -rf / ).
  • We cannot do this with any good result. We can never protect 100%. Not even 1%. It is much better to add the authentication and focus peoples attention to the safety implication of not securing the control access. -- KennethLavrsen - 17 Apr 2005
• Implement Raw mode instead html ( to make easier to parse from frontends ). [done]
• Add restart action. [done]
• Add track auto. [done]
• Add links to list-view pointing to correspondig option dialogue. [done]
• Dessign of html interface ( css , javascript , etc ... ).
• Add the parameter output=text to any request to get raw data from http control. [in progress]
• Fix a weird bug that only affects to FreeBSD ( sscanf( ... , "%a[a-z]",&string); doesn't work ). [done]
• Others.

Download

To try the new feature download the latest Motion snapshot.

• Download motion-20050826-051002 daily snap .
• Please apply this patch

Change History of Patch

Discussion and Comments

---

• Added a patch that allow to write all config files from main thread ( i.ex http://127.0.0.1:8080/0/config/writeyes ) and only the selected config file from a thread ( i.ex http://127.0.0.1:8080/1/config/writeyes ).

-- AngelCarpintero - 26 Aug 2005

---

Discussion on saving config files.

A small mini discussion on the above suggested patch. I find it confusing and I have a few idea which will cost a little more code but should be much more user friendly and enhance the config feature.

Basics

• When Motion load config parameters it first loads the config parameters from motion.conf.
• Then it loads the thread config files. Any config parameter found in these overrides the motion.conf value.

httpd control today

• If you change a value in a thread this value becomes unique for the thread.
• If you change a value in thread 0
  • All threads not having a unique value will use the new thread 0 value
  • All threads having a unique value will ignore the change in thread 0
• If you save config files ALL files are saved.
  • If a thread value is the same as in thread0 it is not saved in the thread config file.
  • If a thread value is different from thread0 it is saved in the thread config file. This means that it is not possible to set and save a unique thread value if it happens to currently be the same as in motion.conf. You have to do this in the file.

The patch submitted

• If you save config in a thread other than 0 the behavour is in my oppinion confusing. People will wonder where there just set value is gone.

New proposal

We change a few basic principles in the way config files are saved and we need two new features in httpd control.

• When you set a value in a thread file it becomes unique as today.
• There will be a new button or link called "reset to global" or something like that. We need to think a little about presentation. Can you see the global value?
• Saving config files from thread 0 does not as today purge any values that are the same in motion.conf and thread#.conf. Any value that has been loaded earlier from thread config file or from later httpd control changes are saved in the thread config file no matter the value in thread0
• In "All" we add a new action that does the same clean-up saving of all config files as we know it today.

To implement this we need to

• Obviously add the functions to the webhttpd code.
• Modify the conf.c code so that is can save both with and without the "clean-up".
• English speaking person: Please suggest some good keyword for the user interface and Motion Guide. "Clean-up" is not very good I think.

Remember this is a proposal. Not a decision.

-- KennethLavrsen - 27 Aug 2005

---

I'd like to consider extending this a little.

First, at the moment when we "save" config values we simultaneously "save" a (verbose) explanation of the parameter, it's default, and the actual setting whenever it has been explicitly specified. This is very good for the novice user, but for the more advanced user it makes it a little difficult to highlight the precise items which differ from the "default". I'd like to see two options: the first would specify "Full" or "NoDescr", and would control whether the "verbose" description is produced in the saved file; the second option would control whether all options which were set in the user's startup configuration (or have been changed during the current run) are saved, or only those options which differ from the "default". For thread0, the "default" would be what is compiled into Motion; for the remaining threads, the "default" would be what is (currently) set in the thread0 configuration (perhaps a checkbox labelled "Only Differences"). Note that this second option is approximately what was previously described as "clean-up".

Note that there will always be a problem about the sequence in which things are done. If the user changes a thread (not 0) configuration param to the default (or thread0) value and saves it with "Only Differences", it (obviously) will not be saved. If he then changes the thread0 value of that particular param, what does this mean (i.e. what is the user thinking)? The answer, of course, is that there is really no perfect solution to that, since the software can't know what those thoughts are :-).

-- BillBrack - 27 Aug 2005

---