On Feb 17, 2010, at 2:34 PM, Markus Karg wrote:
> * My generic client will be embedded in scripts (or possibly, thanks to a
> Java API, in Java code). The script allows me to define a workflow. The
> workflow might cover lots of different services and can be Groovy, Bash,
> Java, whatever. The knowledge about the workflow is solely in the script.
> The client has no knowledge about anything but http and REST. The script has
> no knowledge about http but solely about the workflow, MIME content and
> URIs. Just as I can use cURL in a bash script to upload / download stuff and
> cURL doesn't know what actually I'd like to achieve, in the same way will my
> generic client be workflow-agnostic and application-agnostic, but still can
> drive *any* workflow with *any* server application.
This makes more sense. But I wouldn't call this a "generic client", this is just a "client framework". You're factoring out the common pieces that most clients would need; the actual clients are now in the scripts that have domain knowledge about the problem you're trying to solve.
There may be a difference in what gets factored out, but architecturally, I don't see any difference with the existing frameworks (whether the common components are factored out in an executable, a library, or whatever is just an implementation detail IMO).
-- Santiago