Re: [cpp-netlib-devel] Comments about the HTTP client interface

[Divye K. <div...@gm...>]

Hi Kim and Dean,

On Thu, Aug 28, 2008 at 12:55 PM, Dean Michael Berris <
mik...@gm...> wrote:

> Hi Kim,
>
> On Thu, Aug 28, 2008 at 2:47 PM, Kim Gräsman <kim...@gm...>
> wrote:
> >
> > On Thu, Aug 28, 2008 at 03:47, Dean Michael Berris
> > <mik...@gm...> wrote:
> >>
> >> For #2:
> >> - It puts the method crafting a 'run-time' action, which introduces
> >> if's and control-flow branches that I would like to be able to
> >> eliminate at compile time otherwise
>

It is quite likely that applications that base their decisions on "inputs"
from the user will have to create a switch-case logic in their client code.
It would save a lot of work for various users if the switch-case is
implemented as a generic perform(...) method which throws an exception on
invalid methods.

>
> >> - Type safety (?) is broken because now the users will be able to
> >> perform 'unsupported' or 'ill-formed' HTTP requests
> >
>
Not necessarily, see above.


>
> > I can't think of one off-hand, but I think there may be cases where it
> > makes sense to let the calling code vary the verb dynamically.
> > Essentially, something like:
> >
> >  client.request("POST", headers, body);
>
>
>

I would see client.perform(request, method) as a useful addition to the
client interface as it handles a common use-case.



> 1. The request object is nowhere to be found (http::request object),
> which should encapsulate all this information (headers, body) already
> which is of very little consequence to the client.


The client requires information about the request type (GET, POST etc) and
the request object. We are simply providing the request type as a runtime
string rather than as a static method. I realize that it will cause a
performance penalty due to control paths being included in the code, but
this can be treated as a convenience function that will reduce the number of
ugly switch-case constructs in the client code while enforcing method
validity by exceptions.

3. This means inside client::request(...) I'll have to check whether I
> will ignore/use the body depending on the method string provided.
> Contrast that to a fixed interface which actually at compile time only
> puts the code that's needed to perform the request without having to
> do checks of what to do at runtime.
>

Users who want such a type of dynamic functionality will have to implement
such a dispatch table in any case. This function could simply provide a
dispatch table for each of the typed functions as a convenient shorthand. It
localizes code that would otherwise have to be rewritten in different
applications. For those who already know the type of request to make,
choosing one of the static methods would still be a better option.


> The static mapping between the behavior of client::get and HTTP GET
> requests is intentional because primarily:
>
> 1. I don't see a point in making it a run-time check when it can be
> made clear at compile-time.
> 2. The semantics of usage are unclear when using 'dynamic' or runtime
> values to do the decision making that can otherwise be done at compile
> time in a clearer manner.
>
I would say:
1. Use the typed functions when you already know which type of request to
make.
2. Use the generic function if the decision is based on runtime variables.
However, be aware of the performance pitfalls and the possible exceptions.


>
> If helping the developer avoid shooting themselves in the foot matters
> (which I really think does, a lot) then keeping the static mapping and
> semantics intact would be a good premium. I'd think it's more a
> feature than a deficiency that the HTTP client allows for an
> expressive interface to allow users to "say what they mean" instead of
> leaving a wide open door to allow users to easily get things wrong.
> One of the goals is to make it easier to use the library, and part of
> that is to make 'getting it wrong' harder than getting it right. :)


This would count on  my list as an ease of use feature with the possible
performance penalties dissuading me from indiscriminate use. However, I
acknowledge the merits of retaining a static only mapping to methods. I
would be happy sticking to the static-only mapping if this feature is felt
to be against the good sense of making 'getting it wrong' easier.

> Well, 2c worth,
>
> 2c is a worth a lot from where I am. :-P
>

Same here :-)

Divye Kapoor

-- 
An idealist is one who, on noticing that a rose smells better than a
cabbage, concludes that it will also make better soup.
H. L. Mencken (1880 - 1956)
My official web site: http://people.iitr.ernet.in/shp/061305/
Webmaster: http://www.drkapoorsclinic.com
Blog: http://divyekapoor.blogspot.com