2010-04-23 Astushi Enomoto <atsushi@ximian.com>

	* Http_listener_notes.txt: update comment, as I have fixed one issue
	  with lengthy explanation.

svn path=/trunk/mcs/; revision=155993

diff --git a/mcs/class/System.ServiceModel/ChangeLog b/mcs/class/System.ServiceModel/ChangeLog
index 36db2b0df36db1dc7bf30c2876455648b28bee1a..0bb3d5ac1c3d0912c2ac7fa6577128a1619b4f91 100755 (executable)
--- a/mcs/class/System.ServiceModel/ChangeLog
+++ b/mcs/class/System.ServiceModel/ChangeLog
@@ -1,3 +1,8 @@
+2010-04-23  Astushi Enomoto  <atsushi@ximian.com>
+
+       * Http_listener_notes.txt: update comment, as I have fixed one issue
+         with lengthy explanation.
+
 2010-04-21  Astushi Enomoto  <atsushi@ximian.com>
 
        * Http_listener_notes.txt: more comment.

diff --git a/mcs/class/System.ServiceModel/HTTP_listener_notes.txt b/mcs/class/System.ServiceModel/HTTP_listener_notes.txt
index 55c33a75c3ff41a6dfade966c31c584b4cbbccef..54374d7a5de6d3c09e2b44515fd6a3fae2551c12 100644 (file)
--- a/mcs/class/System.ServiceModel/HTTP_listener_notes.txt
+++ b/mcs/class/System.ServiceModel/HTTP_listener_notes.txt
@@ -15,6 +15,7 @@ This mostly explains what our WCF does, and does not explain what I think it rea
 -- It is important to understand that during this process it populates HTTP channel listener onto the *same* port and even possibly onto the same target URL, differentiating only by the request parameter (e.g. "?wsdl"). This causes a lot of confusion on both IHttpHandler (for ASP.NET) and HttpListener (for non-ASP.NET).
 - Inside (abstract) HttpChannelListener`1, it internally has (abstract) HttpListenerManager which manages the actual HTTP listeners.
 -- This intermediate stuff is required to manage HTTP listeners across the actual HttpChannelListeners because more than one channel listeners might use the identical HTTP listener; only one HttpListener can listen to a specific URI prefix, while (as explained above) WSDL support dispatcher may listen to the same URI only differentiating the query parameter.
+- While building ChannelDispatcher inside ServiceHostBase, we have a tricky code that sets ChannelDispatcher to HttpChannelListener. It is to make sure to apply ServiceMetadataExtension to the listener internals. Without that info, it is not possible to handle wsdl requests precisely (or if you have any simpler idea to achieve this safely, we would glad to hear it).
 
 
 ** non-ASP.NET-specific process flow
@@ -64,7 +65,5 @@ There is not a few bugs on service implementations and there often are reasons:
 
 ** Required changes
 
-- HttpChannelListeners (Simple-, AspNet-) need an owner ServiceHostBase (could be a ChannelDispatcher which is bound to a ServiceHostBase). It has to be set probably at ICommunicationObject.Opening event.
-- After having ServiceHostBase to manage a HttpChannelListener for each endpoint URI (create new or reuse), the listener has to differentiate HTTP requests to an appropriate channel, by EndpointDispatcher.FilterPriority.
-- A big problem is that there is *no* strict way to access to bind a ServiceHostBase or ChannelDispatcher to IChannelListener implementation and hence HttpChannelListener. We can add a special internal field for them to ChannelListenerBase and set them internally at ServiceHostBase, but what IF the IChannelListener is *no* ChannelListenerBase? WSHttpBinding used to have a problem that GetProperty<T>() didn't run through its internal listeners. It is no surprise that a user creates an IChannelListener wrapper for base internal channels. In such case, internal property setters won't work AT ALL.
-  -> There is likely a hope. BindingContext.BuildInnerChannelFactory() explicitly rejects such cases that the BidningElementCollection does not contain a TransportBindingElement. So, it could be sort of assumed that HttpTransportBinidngElement is a top-level binding element that can be accessed when building a listener.
+- HttpChannelListeners (Simple-, AspNet-) need an owner ChannelDispatcher. It has to be set probably at ICommunicationObject.Opening event.
+- After having ChannelDispatcher to manage a HttpChannelListener for each endpoint URI (create new or reuse), the listener has to differentiate HTTP requests to an appropriate channel, by EndpointDispatcher.FilterPriority.