While wsclient offers an excellent means to access rest and soap webservices through its UI and with rules, its does not offer full entity api access to this web service data; making it difficult to leverage the power of views, for example, in querying this data.
The project wsdata intends to do precisely this, as their page states: "This module allows you to bypass the default data storage location for fields and entities and instead load the data from a web service."
Creating "remote entities" with wsclient is currently possible, but only if you create a local entity version of the remote data and then keep them synchronized. For this you may choose to recreating the remote entity using ECK, then build your synchronization logic using rules, but this process can prove resource intensive, and would be completely circumvented when this feature request is realized!
So this feature request is intended to adapt the code base, and embed the capabilities of wsdata directly into wsclient: as WSClient 7-x.2.0.
Note a corresponding request can currenly be found on the wsdata issue queue at: http://drupal.org/node/1964010.
What are the thoughts on this: should these projects be merged or remain seperate?
Comments
Comment #0.0
freddura commentedRemoved 'the'
Comment #1
mmlabelle commented1 vote for a merge
Comment #2
minoroffense commentedWhile having interoperability between the two would be ideal (and I plan on doing so) the two modules should probably remain separate. Wsdata (and more specifically wsfields) does most of it's processing at the field storage level. Meaning we actually replace your database fields with a web service. No data (other than cache) is copied and saved to Drupal.
When we get to entities, we'll have a similar configuration but with the entity controller class.
Wsclient allows you to consume web services and use that data in Drupal but I don't think it's meant to replace how entities and fields are stored.
But as I said, there are points or cross compatibility between the two. For instance our restclient module could enhance the one within Wsclient. We could also ensure that Wsclient can be a configured "connector" for loading data into wsdata.
With that said, I'd say the two should remain separate but ensure we remain good neighbors ;-)
Comment #3
klausiWsclient is designed to only execute operations and process results with Rules. It does not provide any virtual remote entity that handles data access transparently, as wsdata seems to do.
So I also think the 2 should stay separate, but feel free to provide patches or ideas if you need them to interact.
Comment #3.0
klausiAdded 'completely'