[Ovmsdev] Development

Wed Jan 15 10:19:50 HKT 2014

Thanks Mark. I have Drupal 7.25 installed now and I can install that module
and get the tables installed probably Friday or Saturday now as I am away
for the next couple of days.

I have started looking at OAUTH and there are a few drupal modules around
so I shall look at them and see if they might help. I am not a drupal
expert and I have never used it before (my main CMS is Joomla and a bit of
Wordpress) but to be honest, one php CMS is similar to the next so I should
have too much trouble getting up to speed.

Yes, I am happy for you to leave the drupal/php to me... just don't expect
miracles. I will take a while to get up and running but that side of it
does not worry me.

Regards

Paul

On 15 January 2014 00:19, Mark Webb-Johnson <mark at webb-johnson.net> wrote:

> 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/ovms_server.sql
>
>
> 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 at 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 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.
>>
>>
>>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140115/08758f4c/attachment.htm>