<div dir="ltr"><div><div>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. <br>
<br>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.<br>
<br></div>Design by committee will not result in a sound overall design IMO. <br><br></div>Paul<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 22 May 2014 10:27, Christopher Cook <span dir="ltr"><<a href="mailto:christopher.cook@webprofusion.com" target="_blank">christopher.cook@webprofusion.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>I'm easy either way, whatever suits
everyone else.<br>
<br>
By the way I'm in the process of a bug update to the OCM API
documentation, which is always at: <a href="http://openchargemap.org/site/develop/api" target="_blank">http://openchargemap.org/site/develop/api<br>
</a><br>
There is now also a sandboxed API for testing.<br>
<br>
Chris<div class=""><br>
<br>
On 22/05/2014 15:46, Paul Churchley wrote:<br>
</div></div><div class="">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Hi,<br>
<br>
</div>
<div>There is a design principle at play here that we would do
well not to ignore and that is encapsulation.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>For OCM to pull data from OVMS, or any system from that
matter, is the wrong way to apporach this IMO.<br>
</div>
<br>
</div>
Paul<br>
</div>
<div class="gmail_extra"><br>
</div>
</blockquote>
<br>
</div></div>
<br>_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
<br></blockquote></div><br></div>