Paul, The openvehicles.com site is using Drupal version 7. We have written one custom module (openvehicles.module) which provides the VEHICLES tab on the account. You can find the code for that at: https://github.com/markwj/Open-Vehicle-Monitoring-System/tree/master/drupal [HINT] That should form a pretty good basis for what you need. We had a lot of trouble creating that module, but it works well and is stable now - the biggest issue was caching in the drupal code. We would make a change to the module, try it, but the change would not work. Turns out the drupal code for detecting a module has changed on disk is not 100% and only some changes work correctly. Changing things like hook functions don't seem to get picked up. For development, you really need to install the drupal development modules/tools, and those include a button to clear all caches. Get in the habit of hitting that button any time you change the module on disk. [/HINT] There are also some SQL tables that need to be (manually) included. You can find the schema here: https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/server/... We currently use PHP 5.2.9 on www.openvehicles.com. There is a OAuth2 server drupal module here: https://drupal.org/project/oauth2_server but I really don't know if it is any good or even does what we want. It would be great if you could handle the drupal/php side of things, and I can then concentrate (and handle) the perl side. Regards, Mark. On 14 Jan, 2014, at 4:50 pm, Paul Churchley <paul@churchley.org> wrote:
Thanks for taking the time to explain Mark.
I'd love to help with OAUTH if I can. I will need a copy of the drupal site. I will need to set up a development version of the site on my own server to work on.
I will start to read up on OAUTH now!
:-)
Paul
On 14 January 2014 01:06, Mark Webb-Johnson <mark@webb-johnson.net> wrote: Paul,
For github, I find there are just 3 key concepts to understand. They are kind-of counter-intuitive, but once you grasp these you'll understand it better.
You will be used to working with centralised repositories, where people checkout stuff, make changes, and commit it back. Github doesn't work that way. It is not really centralised, and everyone works on their own. So, if you want to get stuff from a repository that you want to be able to change, the trick is to fork the repository. That makes a copy in your own github account that you can work from. Now, there are two repositories for the same code (yours and the place you forked from). (P.S. If you just want to get stuff but not change it, then "clone" is fine.)
The second strange thing about git (and github) is that when you get a local copy of the repository, you are getting the _entire_ repository, including the history of all changes to it from day zero. With something like svn/cvs, you would just get a specific revision, but with git, you get the whole thing. The disadvantage is space and bandwidth. The advantage is that you can do all your revision control work locally (commit, revert, log, switch branches, etc) without Internet connectivity. Clone the OVMS repository, and work on it for a long plane flight - including committing changes, working with branches, etc. Once you are back in civilisation, you can synchronise your local changes with the repository it is cloned from (so long as you have write access - which you will as you are just working on your own forked version of the repository).
The third thing just follows on from the first two. Pushing and Pulling. You will be making changes to your local forked copy of the repository, but at some time you are going to want to synchronise with the upstream version you originally forked from. To pull in changes made upstream since you forked, you just pull/merge in the master repository you originally forked from) - in general you should do this often, to stay up to date and to reduce the chances of conflict with local changes you are making. To contribute back to the master repository, you send a pull request to the maintainers of the master repository (for the OVMS vehicle firmware there are 3 currently). The maintainers will review your changes, and if all is ok merge them into the master repository.
From the coding point of view, I really want to sort out the HTTP API, but that means getting OAUTH working. It would be great if you have time to help with this - but I guess it is new to both of us. From the perl point of view, I can handle it. The issue I have is the overall framework and getting an OAUTH server working in PHP under drupal www.openvehicles.com. What we need is:
The user App goes to www.openvehicles.com for authentication. He logs in, and the server presents him with a list of permissions (e.g.; read gps location, read historical data, read battery status, etc) that the user can give the app. The result is an authentication blob that goes back to the App. This is PHP code in drupal.
The App then goes to the api, presents the authentication blob, which the api server then validates and returns a security token. This is perl code in the OVMS perl server.
The App then goes to the api, presents the token, and gets the data requested. This is perl code in the OVMS perl server.
We need an Apps screen on the www.openvehicles.com server, which shows the user which Apps he has authorised, and allows him to revoke those authorisations.
This is standard OAUTH, and if we follow the standard, client side Apps will be easier (using standard libraries) and it will be simpler to work with third parties (such as IFTTT). The issue is that the coding of OAUTH servers seems very poorly documented, in either PERL or PHP/drupal.
Once we've got the authentication framework resolved, finalising the API should be relatively simple. It would be great if you can help with the OAUTH stuff in PHP+drupal.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev