--- alan runyan <[EMAIL PROTECTED]> wrote:
> The only 'integration' point that was claimed > 'stable' was using PHP api's > which are a layer around the relational database > structure. Plone is written > in Python. So the obvious mechanism to integrate > would be to read/write > directly against the RDBMS. This is a start! But I > dont like this approach. > agreed. i think this path is best avoided > IMHO, the better way would be to integrate as though > CivicCRM was a 'service'. > i.e. REST, XMLRPC, SOAP, etc. This way the RDBMS > structure can change and > does not impact client code. > yes. but to a large extent this depends on client needs etc and what amount of integration is needed. Our drupal integration is quite solid and fairly deep (as such there are other drupal modules that now depend on civicrm api's). Our joomla integration is fairly superficial (but serves the needs of a fair number of people, this will change when Joomla! 1.5 is released). I suspect as a first step some lightweight integration might meet the needs for quite a few orgs :) > > Big questions (from my point of view): > > - When will CivicCRM have a service based > integration point? i.e. all the > functionality that that PHP interface provides will > be exposed via > HTTP/SOAP/etc? > all our new api's are SOAP friendly. The older api's use PHP objects etc, which i suspect are not the best thing for SOAP. Over a period of time, we will convert it. Note that the number of lines of code to "expose" a specific api via a SOAP interface is 5. I suspect we can generalize this and make it 1 :) So its not a big deal for us to "SOAP"ify our current api's :) (though folks might have issues about "incomplete" documentation etc) lobo _______________________________________________ NGO mailing list [email protected] http://lists.plone.org/mailman/listinfo/ngo
