On Feb 18, 2010, at 1:39 PM, Markus Karg wrote:
>>> 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.
>
> What I describe is like using FireFox.exe in a batch, providing a command
> line parameter that it shall browse to a web site, print it and then close.
> If that is a framework for you, ok, then call my generic client a framework.
> I have no interest in another discussion about terminology. ;-)
>
> But the difference that I wanted to point out is less about the way to
> trigger it but more about the fact that what I want to provide is a
> ready-to-use product (like a browser is a ready-to-use product) and less a
> component or library (which is *used* to build a product).
>
> Said that, how does it relate to the Jersey API? The idea is (a) I don't
> like the idea that one *must* write a client using the Jersey API, but *can*
> use such a generic client like mine as a replacement, and it will work with
> any application written using Jersey. (b) The Jersey API must be done in a
> way that the resulting client will work with peers written with different
> APIs. Just like any browser can surf any web site without the need to
> download a plugin or configure anything.
>
> So the main difference between my idea and yours is that what I am having
> extracted in an external workflow is pure business -- the core workflow,
> what a man would do if it would use a browser. But as I understand you
> proposal, with the Jersey API I would have to provide not only the business
> logic, but also a technical plugin that makes the client learn about
> technical aspects of the peer (like what headers it will use). THAT is the
> main difference I see.
>
> The "generic" idea is about the fact that my client will be agnostic of the
> server's application. Your's will not be agnostic, but essentially needs a
> configuration to learn where to find the links.
>
OK, I think I understand now. But (you knew a "but" was coming - right) how do you think a generic client will find the links and know what to do with them. E.g. suppose a service uses media type application/widgets+json, how will the generic client identify the links in the representations and how will it know what HTTP methods are to be used without some additional configuration ?
As a standalone product how can it move beyond the initial steady state ? For browsers with human drivers this is easy, but for a headless generic client I don't see how it could work.
Marc.