[Ovmsdev] Open Charge Map

Paul Churchley paul at churchley.org
Thu May 22 17:46:44 HKT 2014

I don't think it wise just leave such a decision to "what suits everyone
else". It should be designed according to good design principles and good
practice. Just because it is open source and community-driven it should
still not compromise on industry-accepted principles.

If we leave it to what is convenient to others then we will end up building
in problems for everyone further down the line. Of course we must consider
everyone's views in the mix but at the end of the day we should not
compromise on what we know to be sound design principles if we want to have
a system that is flexible to further needs.

Design by committee will not result in a sound overall design IMO.


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

>  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
> _______________________________________________
> 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/263b2bc8/attachment.htm>

More information about the OvmsDev mailing list