> > 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.
>
> We should devise a framework test ... If it looks like a framework,
> lets you write scripts like a framework and lets you execute scripts
> like a framework, it's probably a framework :)
>
> Regardless of the naming issue, I'd be interested in taking it for a
> spin once it's ready. So let us know.
As I already asked Marc: If cURL is a framework for you, then (for the sake
of terminology) call my product a framework, too. But the point I'd actually
liked to explain was not the packaging, but the word "generic": I don't want
that the client must know anything about the server but solely the name of
the links. Not how they are packaged or where to find them. That was the
starting point of the discussion and I'd like to come back to it. With
"generic" I meant that the place where to find links is fixed, just as the
meaning of all http headers are fixed. A generic client (independent whether
it is a standalone product or a component or library) shall be able to talk
to any application. The only thing I want to tell it is: What is the name of
the link to follow? But not, what is the technology that the server
application is using to send the link. Why? Because it makes
interoperability much easier.