Thanks for the comments. Very much appreciated.
Answers interleaved.
On Wednesday 12 September 2001 8:49 pm, you wrote:
Mostly nit picking...
At 10:45 9/11/2001 +0100, andrew wrote:
The proxylet engine interacts with proxylets via interfaces from the
org.ietf.opes.proxylet package. The protocol-specific proxylet
extensions are found within the a sub package from
org.ietf.opes.proxylet. For example, HTTP proxylets use the package
org.ietf.opes.proxylet.http.
I would have assumed that it should be IANA rather than IETF in that
hierarchy.
I'm happy to go with whatever the group thinks best. Does IANA support more
groups than IETF? I dont know much about this kind of thing. The hierarchy is
mostly about preserving namespace, so anything appropriate (and short) will
do. If the IETF gets involved with many java API's there ought to be a
standard policy for package naming. org.ietf.<working group>.<section> would
work (or org.iana... if thats more appropriate ).
protocol message types. For example, HTTPProxylet
will have modGetRequest and a modGetResponse methods dealing with the
adaption of a HTTP GET requests and its subsequent response message.
I'm not a Java programmer (so might be missing something), but wouldn't it
make sense to make these something like:
<mumble>.http.get.modRequest
<mumble>.http.get.modResponse
The same object would probably be used for handling both a GET and a POST
request. Therefore I've included all the methods in the same interface
allowing the programmer to choose which methods to implement.
NB. the interface will be implemented for convenience with all empty methods
in an EventAdaptor like way.
6.1 Cookie
Cookie represents the access interface for HTTP-like cookies. A
cookie is a name value pair that is associated with a request, and
assigned to the user as part of the response.
Cookies are associated with responses too. s/user/user agent/
Yes
Cookie.getValue() with no parameters certainly seems to assume a single
cookie in the request/response. There could be many.
This cookie object only has one value, the Cookie object is extracted for
HTTP from HTTProxyletRequest by the method getCookie( name ). This method
will return an iterator over a collection of these cookie objects.
I suspect Cookie.getName() should return a list of names.
Simillarly HTTPProxyletRequest has getCookieNames which again returns an
iterator over a list of names.
Same problem in Cookie.setValue() - assumes there's only one cookie's value
being set.
I see similar problems in 6.13 (just skimming the document after 6.1,
sorry).
(Are you assuming cookie header concatenation in the above?)
[OK, I'm just re-reading parts of this... is 6.1 an *internal* cookie? It
seems my comments above are addressed later in 6.1[45], which suggests the
wording in 6.1 might need improvement to identify the scope.)
In 6.15, HTTPProxyletRequest.getHeader() string concatenates a header. The
corresponding .setHeader() I assume creates a single concatenated header in
the new HTTP header... While there's an issue of "but 2616 says..." here, I
think this is somewhere it might be better to err on the side of caution
and allow for non-concatenated headers. Of course, there's an ordering
issue to be considered here.
Order is preserved in the HTTPProxyletRequest collection.
Regards
Andy