> > * 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.
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. 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.