[Ovmsdev] Development

[Paul Churchley]

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 at 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.
>
>
>    1. 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.)
>
>    2. 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).
>
>    3. 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:
>
>
>    1. 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.
>
>    2. 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.
>
>    3. The App then goes to the api, presents the token, and gets the data
>    requested. This is perl code in the OVMS perl server.
>
>    4. 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140114/79fe581c/attachment.htm>