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.

Paul

On 22 May 2014 10:27, Christopher Cook <christopher.cook@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@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev