> > 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.
It's hard to describe, but I hope you understand what I try to explain?
> Again that sounds exactly like a framework to me.
Ok, then Firefox is a framework, since I can call it from bash. Nothing else
would I do, besides the fact that mine will not be able to visually render
html but instead is able to retrieve links from content and the "Link"
header.
> 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.
But you cannot execute it as a standalone product. But you could do with
mine. Just like cURL. Is cURL a framework for you, too? Anyways, it's of no
interest to further discuss this, as the main thing I wanted to say is not
what I like to write but more that I don't like the idea that the client API
needs to know anything about the server application or the framework used.
This is the main difference, as I explained above.
> > 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.
Well... actually I think the main difference between a standalone product
like "Internet Explorer" and a framework like Microsoft's "HTML Browser
ActiveX Compontent" *IS* solely the packaging... Anyways, forget about it,
the core point I'd like to point out is (again) that I don't want that the
client must know what the server framework or the application works like,
but *just* what the name of the link is -- not how it is getting sent.