<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><br><div class="gmail_quote">On 22 May 2014 03:20, 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>Hi All,<br>
      <br>
      To be clear, there is no concrete requirement (from the OCM
      perspective) for OVMS to use the OCM API to checkin nor for OVMS
      to authenticate/link OCM users - it's just something that could be
      done if desired. As J-C suggests the checkin can appear
      anonymously as 'An OVMS User'. The check-in information can be
      published into OCM either by using the OCM API to check-in
      anonymously or by OCM pulling check-in data from the OVMS API.
      Thats fine and the end result is the same for most people. The
      disadvantage of not associating the check-in with an OCM user is
      that the user can never go back and remove/amend their checkin in
      OCM, which may or may not be an issue for them. If we're pulling
      from the OVMS API then the question is can we hold identifying
      information about the user (an ID etc) so that we can reconcile
      them later if they wish to link their accounts?<br>
      <br>
      Behind the scenes OCM holds a User Reputation score which
      increments when you add/edit a POI or add any comment/photo, some
      users would probably like their automated checkins to count
      against that when we get around to having a leaderboard of some
      sort - so that's a potential scenario for linking user in the
      future.<br>
      <br>
      By submitting data into the OCM API, the data becomes CC BY 3.0
      licensed (by association that using the API is acceptance of those
      terms), whereas OCM pulling from OVMS is subject to whatever
      applicable license there will be there and if the data will be
      aggregated/anonymous etc. Likewise other charge map vendors will
      likely want to use the API to pull data into their own systems.<br>
      <br>
      Chris<br>
      <br>
      On 22/05/2014 03:29, J-C Saint-Pô wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div>
                    <div>Maybe people use their ovms usercode to write
                      changes & comments to ocm to an cooperationg
                      ovms server<br>
                    </div>
                    This server writes the changes & comments to ocm
                    as "OVMS-user-submitted"<br>
                  </div>
                  Maybe give ovms users possibility to choose to submit
                  directly to ocm for submitting more ample info<br>
                </div>
                And use the "via-ovms" for basic changes or submissions<br>
              </div>
              All will depend on how much load you want on the
              ovms-server<br>
              <br>
            </div>
            (suggestion submited by someone who only knows the basics on
            computers & co) ;-)<br>
          </div>
          Kind greets<br>
        </div>
        JC<br>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">2014-05-21 19:04 GMT+02:00 Lee Howard <span dir="ltr"><<a href="mailto:lee.howard@mainpine.com" target="_blank">lee.howard@mainpine.com</a>></span>:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello
            Mark, Chris, and other OVMS users and developers...<br>
            <br>
            I am happy with all of Mark's outline with only one point
            for debate. Admittedly, I am new to OpenChargeMap API and
            OVMS programming, and so maybe I simply don't understand how
            things work, but...<br>
            <br>
            As the OVMS server will be performing the OpenChargeMap API
            on behalf of the partner instead of the portable app
            performing the OpenChargeMap API (more-directly in the
            control of the partner)... is it really necessary for the
            OVMS server to masquerade as the partner... using their
            identity for authentication with OpenChargeMap?<br>
            <br>
            I'd prefer to avoid requiring the user to set-up an
            independent account with OpenChargeMap and then permit OVMS
            to operate on behalf of that newly-created account. Could
            not the OVMS server simply use its own account (for
            everyone) and simply provide an information field about the
            identification of the OVMS user?<br>
            <br>
            My primary interest here is in making it as simple as
            possible for the OVMS user to opt-in. Requiring them to sign
            up with OpenChargeMap and provide a PIN or key from the
            account is an additional step that will prove to be a
            barrier for users that are willing to opt-in as long as it
            is merely as easy as a button-press.<br>
            <br>
            Thanks,<br>
            <br>
            Lee.<br>
            <br>
            <br>
            On 05/21/2014 04:12 AM, Christopher Cook wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              ....[snip]....
              <div><br>
                <br>
                One option I'm pondering is for apps to be able to
                request the OCM Session Token just by supplying a PIN
                code and Username to the API, the user would need to go
                to the OCM website to generate the pin code (and conform
                the expected Username for it to work) probably by
                starting a certain OCM url with an API Key specific to
                OVMS.<br>
                <br>
              </div>
              ....[/snip]....
              <div><br>
                <br>
                On 21/05/2014 15:23, Kevin Sharpe wrote:<br>
              </div>
              <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div>
                  FYI, I’ve asked Lee Howard from Mainpine to take a
                  look at this in detail.<br>
                  <br>
                  <br>
                  Kevin Sharpe | Founder & Patron | Zero Carbon
                  World is a UK Registered Charity #1141347<br>
                  <br>
                </div>
                From: Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" target="_blank">mark@webb-johnson.net</a>
                <mailto:<a href="mailto:mark@webb-johnson.net" target="_blank">mark@webb-johnson.net</a>>><br>
                Reply-To: OVMS Developers <<a href="mailto:ovmsdev@lists.teslaclub.hk" target="_blank">ovmsdev@lists.teslaclub.hk</a>
                <mailto:<a href="mailto:ovmsdev@lists.teslaclub.hk" target="_blank">ovmsdev@lists.teslaclub.hk</a>>>
                <div>
                  <br>
                  Date: Wednesday, 21 May 2014 07:19<br>
                </div>
                To: OVMS Developers <<a href="mailto:ovmsdev@lists.teslaclub.hk" target="_blank">ovmsdev@lists.teslaclub.hk</a>
                <mailto:<a href="mailto:ovmsdev@lists.teslaclub.hk" target="_blank">ovmsdev@lists.teslaclub.hk</a>>>
                <div>
                  <br>
                  Subject: Re: [Ovmsdev] Open Charge Map<br>
                  <br>
                  Here is an email with a proposal / suggest I sent out
                  last year. This would be wonderful to do, just limited
                  resources to do it with.<br>
                  <br>
                </div>
                ....[snip]....
                <div><br>
                  <br>
                      The server will maintain a database of partners,
                  and their API<br>
                      access keys. This database should allow for PUSH
                  messages (via<br>
                      HTTP) to the partner. If PUSH is enabled, every
                  time a charging<br>
                      session is updated (either started or completed),
                  the server will<br>
                      connect to each partner (in randomised order) and
                  send them the<br>
                      information for recent charges. The server will
                  also provide an<br>
                      API to allow partners to PULL messages past a
                  certain date/time<br>
                      stamp (to allow for periodic synchronisation).<br>
                  <br>
                </div>
                    _*Partners*_
                <div><br>
                  <br>
                      Partners would just have to subscribe to the
                  system (signing up<br>
                      with a user account and being given an API key).
                  They would have<br>
                      to agree to the license terms, but other than that
                  there would be<br>
                      no restrictions to partnership.<br>
                  <br>
                </div>
                    ....[snip]....<br>
                <br>
                <span><font color="#888888">
                  </font></span></blockquote>
            </blockquote>
            <span><font color="#888888">
                <br>
                -- <br>
                *Lee Howard*<br>
                *Mainpine, Inc. Chief Technology Officer*<br>
                Tel: <a href="tel:%2B1%20866%20363%206680" value="+18663636680" target="_blank">+1 866 363 6680</a>
                | Fax: <a href="tel:%2B1%20360%20462%208160" value="+13604628160" target="_blank">+1 360 462 8160</a><br>
                <a href="mailto:lee.howard@mainpine.com" target="_blank">lee.howard@mainpine.com</a>
                | <a href="http://www.mainpine.com" target="_blank">www.mainpine.com</a></font></span>
            <div>
              <div><br>
                _______________________________________________<br>
                OvmsDev mailing list<br>
                <a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">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>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <br>
        -- <br>
        <a href="http://home.scarlet.be/jcsaintpo" target="_blank">http://home.scarlet.be/jcsaintpo</a><br>
        <br>
        Get a warning of every update on my site:<br>
        <a href="http://jcsaintpo.notifylist.com/jc_site.html" target="_blank">http://jcsaintpo.notifylist.com/jc_site.html</a><br>
        <br>
        My msn space:<br>
        <a href="http://spaces.msn.com/members/jcstp/" target="_blank">http://spaces.msn.com/members/jcstp/</a>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.teslaclub.hk" target="_blank">OvmsDev@lists.teslaclub.hk</a>
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br>
  </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>