[Ovmsdev] Open Charge Map

[Paul Churchley]

I agree with Tom. That makes sense from a data and functional design
perspective too.

It is best if OVMS remain uncoupled as much as possible and pushes out
updates to OCM for opted-in users through an external system update layer.
That layer could be independent of the main OVMS system and could have
stubs for each data interface that OVMS wishes to interact with. That would
make the design, development and maintenance of this functionality modular,
isolated and easier to develop.

tbh, I would feel uncomfortable with OCM pulling changes in from OVMS. The
update originate from within OVMS and so OVMS should initiate the action
IMO. So, I would prefer to OVMS charging location capture to be generic and
not tied to OCM or to OCM functionality. Of course, OCM and its
requirements will impact on the OVMS design but OVMS should remain,
wherever possible, external system/database agnostic.


On 22 May 2014 22:49, Tom Saxton <tom at idleloop.com> wrote:

> I'd like to make sure that whatever happens with OVMS reporting charging
> station information stays open and stand-alone, not tied exclusively to
> OCM.
>
> When a user chooses to submit data, it should go to OVMS where it can be
> accessed by anyone, whether it's a charge map vendor, some other
> enterprise, or someone doing EV research for some completely different
> purpose.
>
> It's fine if there's a layer of top of that so that OVMS users who opt-in
> to OCM can enter OCM credentials, disambiguate between possible sites,
> etc., and the data also gets sent to OCM.
>
>    Tom
>
>
> _______________________________________________
> 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.teslaclub.hk/pipermail/ovmsdev/attachments/20140522/63ebc73a/attachment-0001.html>