On Thu, Feb 18, 2010 at 10:45 AM, Markus Karg <markus.karg_at_gmx.net> wrote:
...
>> 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
Sorry to rehash this, but I think that "client" usually does refer to
something that handles specific aspect; and frameworks are things that
glue pieces together. So term "generic client" seems inconsistent.
From this POV, I too think that your description sounds more like a
framework than client.
You could call it a hyperlink processor too. :-)
Or hyperlink client, I guess (in that it specifically handles
hyperlinks, and nothing else).
I think that the reason "framework" is implied is that natural next
question is "what else will it do", because:
> 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.
I guess the follow-up question is this: what value does this provide?
Ok, it can find hyperlinks, and execute some code that something else
provides.
Which, assuming that you know vocabulary (and data format in question)
is, well, of some use, but rather minor part. The complexity would be
in choosing which actions to take.
So it would seem like such a thing could be part of client-side
lib/framework: starting point, but nothing very useful in itself.
Which is where extension parts come in.
-+ Tatu +-