<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'><BR>The problem with those classes (request/response) is that they are sealed and have no public constructors; which means nothing but the HttpListener can create those object, which in effect locks the handler to the httplistener.<BR>
<BR>
I would strongly suggest we introduce wrapper interfaces for requests and responses where we extract exactly those methods we see fit to expose in the way that suits us best; this also means we can re-use handlers in other contexts than HttpListener, like in asp or in applications.<BR>
<BR>
Best regards,<BR>
/Stefan<BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Fri, 16 May 2008 11:59:30 +0200<BR>> From: DrScofield@xyzzyxyzzy.net<BR>> To: opensim-dev@lists.berlios.de<BR>> Subject: [Opensim-dev] enhancing IStream(ed)Handler interface to pass in request/response object<BR>> <BR>> still trying to grok BaseHttpServer i'm trying to work out how a <BR>> RestStreamHandler could pass back stuff like content type, result code, <BR>> redirects, checking for access keys or alternative content-type conveyed <BR>> via HTTP request header.<BR>> <BR>> content type it's seems could be done by overriding the ContentType <BR>> property in a subclass of RestStreamHandler --- though, i'd view that as <BR>> the "default" content type. we'd like to be able to supply alternative <BR>> content types (if the request specified that it would accept those), so <BR>> a more dynamic way of setting the content type would be good.<BR>> <BR>> result code i currently don't see how we could return that from a <BR>> RestStreamHandler. likewise redirects.<BR>> <BR>> checking for access keys supplied in the HTTP request is also not <BR>> possible (as far as i can tell, if there is a way, please, let me know :-)<BR>> <BR>> if we were to pass in the HTTPRequest and HTTPResponse objects as <BR>> additional parameters to the IStream(ed)Handler invocations then the <BR>> handler would have access to the HTTP request and could set response <BR>> values as necessary --- any objections to that?<BR>> <BR>> cheers,<BR>> dr scofield<BR>> <BR>> -- <BR>> dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab<BR>> SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/<BR>> RL: hud@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/<BR>> <BR>> _______________________________________________<BR>> Opensim-dev mailing list<BR>> Opensim-dev@lists.berlios.de<BR>> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR><BR></body>
</html>