Now I have taken my first look at the Github I feel rather dejected. I thought I was a reasonable PHP programmer but looking at the code for the vehicle and server I find that I am hopelessly out of my depth from a coding perspective. I know php so the fact it is perl doesn't help. There is a lot of commonality but it is sufficiently different to make it difficult for me right now. It isn't that the code is bad... it isn't bad - it looks great! No, it is just that I think I am so out of practice combined with it being perl I think I am not going to be as much help as I had imagined (hoped)... well, not for quite a while anyway :-( Still, I am sure there are many things that need doing that I can do so I look forward to helping with those. I perhaps just need a bit of guidance on what needs doing that I am actually able to do! I think a crash (or not so crash!) course on perl is my starting point. My php and general programming background will mean I pick up the basics pretty quickly but it is the finer points that will take a while I reckon. I'll start on that this week and then at least I might be able to understand what has already been coded and maybe tackle bugs etc even if I find it difficult to code from scratch. In the meantime, I am also getting to grips with Github... it is also not as easy as I had imagined and I am a little scared that I might do something that corrupts the origin repo! Heeeelp! I am using command line Git and Windows Github at the moment but I am about to install Eclipse so I shall hopefully use that for Git instead as it is all nicely integrated. Does anyone else use Eclipse? I also have Visual Studio 2013 for Windows development. I am wondering if I might be able to create a version of the phone app for Windows phones... would that be useful? I am not a Windows developer but creating Windows phone apps is something I would like to get to grips with so again, it wouldn't be quick but I might be able to come up with something useful. Something else I could probably do is a web interface (or develop the existing one if it already exists) to bring the phone app functionality to the web? Any use? I am very comfortable with databases and mySQL so if there is any database stuff that needs doing I would be keen to be involved. There is so much for me to do to get me up and running it is almost overwhelming! I must just take it a stage at a time. Any guidance/advice on where you think I would be wise to start would be very much appreciated. Any suggestions? Paul PS I am not trying to "muscle in" on any aspects of OVMS... I am just in "brain-dump" mode for now until I find my place in the team... where ever that happens to be! I am cool with doing anything I am able to do... or nothing, if that is preferred :-)
Hi Paul, only partial answer: Am 13.01.2014 um 10:12 schrieb Paul Churchley:
In the meantime, I am also getting to grips with Github... it is also not as easy as I had imagined
You are SOOOO True. ;(
and I am a little scared that I might do something that corrupts the origin repo! Heeeelp!
No. You can't do that. Only Mark can write. You can only work at your own copy.
I am using command line Git and Windows Github at the moment but I am about to install Eclipse so I shall hopefully use that for Git instead as it is all nicely integrated. Does anyone else use Eclipse?
No, sorry. Bye Michael
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. On 13 Jan, 2014, at 5:12 pm, Paul Churchley <paul@churchley.org> wrote:
Now I have taken my first look at the Github I feel rather dejected. I thought I was a reasonable PHP programmer but looking at the code for the vehicle and server I find that I am hopelessly out of my depth from a coding perspective. I know php so the fact it is perl doesn't help. There is a lot of commonality but it is sufficiently different to make it difficult for me right now. It isn't that the code is bad... it isn't bad - it looks great! No, it is just that I think I am so out of practice combined with it being perl I think I am not going to be as much help as I had imagined (hoped)... well, not for quite a while anyway :-(
Still, I am sure there are many things that need doing that I can do so I look forward to helping with those. I perhaps just need a bit of guidance on what needs doing that I am actually able to do!
I think a crash (or not so crash!) course on perl is my starting point. My php and general programming background will mean I pick up the basics pretty quickly but it is the finer points that will take a while I reckon. I'll start on that this week and then at least I might be able to understand what has already been coded and maybe tackle bugs etc even if I find it difficult to code from scratch.
In the meantime, I am also getting to grips with Github... it is also not as easy as I had imagined and I am a little scared that I might do something that corrupts the origin repo! Heeeelp! I am using command line Git and Windows Github at the moment but I am about to install Eclipse so I shall hopefully use that for Git instead as it is all nicely integrated. Does anyone else use Eclipse?
I also have Visual Studio 2013 for Windows development. I am wondering if I might be able to create a version of the phone app for Windows phones... would that be useful? I am not a Windows developer but creating Windows phone apps is something I would like to get to grips with so again, it wouldn't be quick but I might be able to come up with something useful.
Something else I could probably do is a web interface (or develop the existing one if it already exists) to bring the phone app functionality to the web? Any use?
I am very comfortable with databases and mySQL so if there is any database stuff that needs doing I would be keen to be involved.
There is so much for me to do to get me up and running it is almost overwhelming! I must just take it a stage at a time. Any guidance/advice on where you think I would be wise to start would be very much appreciated.
Any suggestions?
Paul
PS I am not trying to "muscle in" on any aspects of OVMS... I am just in "brain-dump" mode for now until I find my place in the team... where ever that happens to be! I am cool with doing anything I am able to do... or nothing, if that is preferred :-)
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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.
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.
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
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@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/...
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.
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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (3)
-
Mark Webb-Johnson -
mikeljo＠mac.com -
Paul Churchley