[Ovmsdev] Open Charge Map

Paul Churchley paul at churchley.org
Thu May 22 15:46:07 HKT 2014


There is a design principle at play here that we would do well not to
ignore and that is encapsulation.

As a general rule there are massive benefits to ensuring that each system
is as much as a "black box" as possible. By that I mean that each system
functions in isolation taking care of its own business and not getting
involved in the business of other systems. Designing systems, programs etc
this way removes, or at least reduces, dependencies and decouples

The way I see the integration of OVMS and OCM is that OCM should remain as
much as possible a static partner. It should provide an API to allow the
adding of locations, checking in, handing out location data etc by anyone.
Where ever possible, it should not be pulling data from other systems if we
want to reduce these dependencies and remain flexible.

Functionally this interface is identical to a person doing the same things
except that it is being automated. We should therefore use the same
processes. This is not a database transfer, or a bulk data load, which
would functionally be initiated by OCM. It is an individual checking in at
a single location and so shouldn't we use the same process... OVMS sends
the data to OCM via the OCM API? Which userid is used to access OCM is
clear to me... it is OVMS that is the source and so there must be a single
user in OCM through which OVMS intefaces with the OVMS user id perhaps
passed to OCM perhaps as a comment or in one of the other API data fields
that makes sense.

For OCM to pull data from OVMS, or any system from that matter, is the
wrong way to apporach this IMO.


On 22 May 2014 03:20, Christopher Cook <christopher.cook at webprofusion.com>wrote:

>  Hi All,
> To be clear, there is no concrete requirement (from the OCM perspective)
> for OVMS to use the OCM API to checkin nor for OVMS to authenticate/link
> OCM users - it's just something that could be done if desired. As J-C
> suggests the checkin can appear anonymously as 'An OVMS User'. The check-in
> information can be published into OCM either by using the OCM API to
> check-in anonymously or by OCM pulling check-in data from the OVMS API.
> Thats fine and the end result is the same for most people. The disadvantage
> of not associating the check-in with an OCM user is that the user can never
> go back and remove/amend their checkin in OCM, which may or may not be an
> issue for them. If we're pulling from the OVMS API then the question is can
> we hold identifying information about the user (an ID etc) so that we can
> reconcile them later if they wish to link their accounts?
> Behind the scenes OCM holds a User Reputation score which increments when
> you add/edit a POI or add any comment/photo, some users would probably like
> their automated checkins to count against that when we get around to having
> a leaderboard of some sort - so that's a potential scenario for linking
> user in the future.
> By submitting data into the OCM API, the data becomes CC BY 3.0 licensed
> (by association that using the API is acceptance of those terms), whereas
> OCM pulling from OVMS is subject to whatever applicable license there will
> be there and if the data will be aggregated/anonymous etc. Likewise other
> charge map vendors will likely want to use the API to pull data into their
> own systems.
> Chris
> On 22/05/2014 03:29, J-C Saint-Pô wrote:
>     Maybe people use their ovms usercode to write changes & comments to
> ocm to an cooperationg ovms server
>  This server writes the changes & comments to ocm as "OVMS-user-submitted"
>  Maybe give ovms users possibility to choose to submit directly to ocm for
> submitting more ample info
>  And use the "via-ovms" for basic changes or submissions
>  All will depend on how much load you want on the ovms-server
>  (suggestion submited by someone who only knows the basics on computers &
> co) ;-)
>  Kind greets
>  JC
> 2014-05-21 19:04 GMT+02:00 Lee Howard <lee.howard at mainpine.com>:
>> Hello Mark, Chris, and other OVMS users and developers...
>> I am happy with all of Mark's outline with only one point for debate.
>> Admittedly, I am new to OpenChargeMap API and OVMS programming, and so
>> maybe I simply don't understand how things work, but...
>> As the OVMS server will be performing the OpenChargeMap API on behalf of
>> the partner instead of the portable app performing the OpenChargeMap API
>> (more-directly in the control of the partner)... is it really necessary for
>> the OVMS server to masquerade as the partner... using their identity for
>> authentication with OpenChargeMap?
>> I'd prefer to avoid requiring the user to set-up an independent account
>> with OpenChargeMap and then permit OVMS to operate on behalf of that
>> newly-created account. Could not the OVMS server simply use its own account
>> (for everyone) and simply provide an information field about the
>> identification of the OVMS user?
>> My primary interest here is in making it as simple as possible for the
>> OVMS user to opt-in. Requiring them to sign up with OpenChargeMap and
>> provide a PIN or key from the account is an additional step that will prove
>> to be a barrier for users that are willing to opt-in as long as it is
>> merely as easy as a button-press.
>> Thanks,
>> Lee.
>> On 05/21/2014 04:12 AM, Christopher Cook wrote:
>>> ....[snip]....
>>> One option I'm pondering is for apps to be able to request the OCM
>>> Session Token just by supplying a PIN code and Username to the API, the
>>> user would need to go to the OCM website to generate the pin code (and
>>> conform the expected Username for it to work) probably by starting a
>>> certain OCM url with an API Key specific to OVMS.
>>>  ....[/snip]....
>>> On 21/05/2014 15:23, Kevin Sharpe wrote:
>>>>  FYI, I’ve asked Lee Howard from Mainpine to take a look at this in
>>>> detail.
>>>> Kevin Sharpe | Founder & Patron | Zero Carbon World is a UK Registered
>>>> Charity #1141347
>>>>  From: Mark Webb-Johnson <mark at webb-johnson.net <mailto:
>>>> mark at webb-johnson.net>>
>>>> Reply-To: OVMS Developers <ovmsdev at lists.teslaclub.hk <mailto:
>>>> ovmsdev at lists.teslaclub.hk>>
>>>> Date: Wednesday, 21 May 2014 07:19
>>>>  To: OVMS Developers <ovmsdev at lists.teslaclub.hk <mailto:
>>>> ovmsdev at lists.teslaclub.hk>>
>>>> Subject: Re: [Ovmsdev] Open Charge Map
>>>> Here is an email with a proposal / suggest I sent out last year. This
>>>> would be wonderful to do, just limited resources to do it with.
>>>>  ....[snip]....
>>>>     The server will maintain a database of partners, and their API
>>>>     access keys. This database should allow for PUSH messages (via
>>>>     HTTP) to the partner. If PUSH is enabled, every time a charging
>>>>     session is updated (either started or completed), the server will
>>>>     connect to each partner (in randomised order) and send them the
>>>>     information for recent charges. The server will also provide an
>>>>     API to allow partners to PULL messages past a certain date/time
>>>>     stamp (to allow for periodic synchronisation).
>>>>      _*Partners*_
>>>>     Partners would just have to subscribe to the system (signing up
>>>>     with a user account and being given an API key). They would have
>>>>     to agree to the license terms, but other than that there would be
>>>>     no restrictions to partnership.
>>>>      ....[snip]....
>> --
>> *Lee Howard*
>> *Mainpine, Inc. Chief Technology Officer*
>> Tel: +1 866 363 6680 | Fax: +1 360 462 8160
>> lee.howard at mainpine.com | www.mainpine.com
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> --
> http://home.scarlet.be/jcsaintpo
> Get a warning of every update on my site:
> http://jcsaintpo.notifylist.com/jc_site.html
> My msn space:
> http://spaces.msn.com/members/jcstp/
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.teslaclub.hkhttp://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/20140522/bd48de3d/attachment.htm>

More information about the OvmsDev mailing list