[Ovmsdev] Open Charge Map

Christopher Cook christopher.cook at webprofusion.com
Thu May 22 17:27:46 HKT 2014


I'm easy either way, whatever suits everyone else.

By the way I'm in the process of a bug update to the OCM API 
documentation, which is always at: http://openchargemap.org/site/develop/api

There is now also a sandboxed API for testing.

Chris

On 22/05/2014 15:46, Paul Churchley wrote:
> Hi,
>
> 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 functionality.
>
> 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.
>
> Paul
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140522/a708533e/attachment.htm>


More information about the OvmsDev mailing list