<div dir="ltr">Thanks for taking the time to explain Mark. <div><br></div><div>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. <br>
</div><div><br></div><div>I will start to read up on OAUTH now!</div><div><br></div><div>:-)</div><div><br></div><div>Paul</div><div><br></div><div><br></div><div><br></div><div><br><div class="gmail_extra"><br><br><div class="gmail_quote">
On 14 January 2014 01:06, Mark Webb-Johnson <span dir="ltr"><<a href="mailto:mark@webb-johnson.net" target="_blank">mark@webb-johnson.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Paul,<div><br></div><div>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.</div>
<div><br></div><div><ol><li>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.)<br>
<br></li><li>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).<br>
<br></li><li>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. </li>
</ol></div><div><br></div><div>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 <a href="http://www.openvehicles.com" target="_blank">www.openvehicles.com</a>. What we need is:</div>
<div><br></div><div><ol><li>The user App goes to <a href="http://www.openvehicles.com" target="_blank">www.openvehicles.com</a> 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.<br>
<br></li><li>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.<br><br></li><li>The App then goes to the api, presents the token, and gets the data requested. This is perl code in the OVMS perl server.<br>
<br></li><li>We need an Apps screen on the <a href="http://www.openvehicles.com" target="_blank">www.openvehicles.com</a> server, which shows the user which Apps he has authorised, and allows him to revoke those authorisations.</li>
</ol></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>
Regards, Mark.</div><div><br><div><div><div class="h5"><div><br></div></div></div></div></div></div></blockquote></div><br></div></div></div>