Hi Sebastian,

> Agreed; $ would be better than _ or ._, so I propose to use it, e.g.
> 
> http.socket.timeout$Integer=1000

One little detail: it might be easy to prepend java.lang. to Integer,
but I would still prefer a different scheme. My suggestion: if the
type is given as a classname, it must be fully qualified (and there
is no support for classes outside of a package). To make things easy
for the elementary types, these are mapped to the corresponding class
in java.lang., like Java itself does in reflections and elsewhere.
So the following two would be interpreted in the same way:

http.socket.timeout$int=1000
http.socket.timeout$java.lang.Integer=1000

The default type is java.lang.String, so these are equivalent:

http.whatever.string.param=value
http.whatever.string.param$java.lang.String=value


Oleg, you mentioned that you would prefer a separate mapping of
parameter names to types instead of encoding the type directly
in the parameter definitions. My main concern is that we would
have to maintain a type mapping that potentially spans across
all components. Application developers that want to use additional
parameters in their implementations would need to extend that
mapping.
While that can be managed by having multiple mapping lists, one
for each component and additional ones for applications that want
to define their own parameters, this seems to be a complex setup
that IMHO we should rather not tackle at this time.
Encoding the type into a property name is a direct equivalent
of the way HttpParams is currently used in the code:

params.setParameter("http.socket.timeout", new Integer(1000));
params.setIntParameter("http.socket.timeout", 1000);
params.setParameter("http.socket.timeout", "1000"); // BAD!

There is no type check here either. Having an implementation
of HttpParams that performs type checks is something I would
consider a future extension, just like a preferences scheme
with separate type mapping.

cheers,
  Roland

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to