On Feb 17, 2010, at 3:02 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.
>
> Actually it is not a framework! Really think it as a browser that is driven
> by a human. BUT there is no human but some script that clicks the mouse and
> scans the content for links. So it is nothing else but a hyper-generic
> scriptable browser that actually does not show anything on the screen but
> gets triggered by the script and answers to the script. Cannot see any part
> of the definition of a framework here.
>
What you are describing sounds just like a framework to me, maybe its just a terminology thing. Essentially I write some code that calls into a [library|framework|whatever] when it needs to progress the state machine. The [library|framework|whatever] handles the details while relying on the external code to provide the necessary logic and metadata to drive the interaction.
> In fact I won't call a workflow a "client" as it is just a sequence of
> logic, while in the sense of C/S still the generic client is the client to
> the JAX-RS server. I just replace the wetware by scripts. In your
> understanding the client won't be the browser but the human would be, what
> is incorrect: Even if I am the person clicking the mouse, the client still
> is not me but the browser.
>
> Anyways, you understood my idea, the rest is kind of definition of wording.
> ;-)
>
>
>> 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).
>
> The difference is that I *do not* write a framework. My generic client could
> be downloaded and used exactly just you download firefox or opera, with the
> sole difference that my client has no window to render HTML but an API for
> scripting.
Again that sounds exactly like a framework to me. JAX-RS is a server-side framework. You download it, write some code that uses it and let JAX-RS do lots of the heavy lifting for you. You don't write the framework, you use it.
> This is a huge difference to the existing frameworks, since those
> target in writing a client. Mine is targeting in a ready-to-use application
> that is scriptable.
>
I don't see the distinction you are drawing, to me it just sounds like a question of packaging.
Marc.