Updated the "TODO" comments.

dlls/rpcrt4/rpcrt4_main.c

@@ -19,15 +19,19 @@
  * 
  * WINE RPC TODO's (and a few TODONT's)
  *
- * - widl is like MIDL for wine.  For wine to be a useful RPC platform, quite
- *   a bit of work needs to be done here.  widl currently doesn't generate stubs
- *   for RPC invocation -- it will need to; this is tricky because the MIDL compiler
- *   does some really weird stuff.  Then again, we don't necessarily have to
- *   make widl work like MIDL, so it could be worse.  Lately Ove has been working on
- *   some widl enhancements.
+ * - Ove's decreasingly incomplete widl is an IDL compiler for wine.  For widl
+ *   to be wine's only IDL compiler, a fair bit of work remains to be done.
+ *   until then we have used some midl-generated stuff.  (What?)
+ *   widl currently doesn't generate stub/proxy files required by wine's (O)RPC
+ *   capabilities -- nor does it make those lovely format strings :(
+ *   The MS MIDL compiler does some really esoteric stuff.  Of course Ove has
+ *   started with the less esoteric stuff.  There are also lots of nice
+ *   comments in there if you want to flex your bison and help build this monster.
  *
  * - RPC has a quite featureful error handling mechanism; basically none of this is
- *   implemented right now.
+ *   implemented right now.  We also have deficiencies on the compiler side, where
+ *   wine's __TRY / __EXCEPT / __FINALLY macros are not even used for RpcTryExcept & co,
+ *   due to syntactic differences! (we can fix it with widl by using __TRY)
  *
  * - There are several different memory allocation schemes for MSRPC.
  *   I don't even understand what they all are yet, much less have them
@@ -37,45 +41,30 @@
  *
  * - MSRPC provides impersonation capabilities which currently are not possible
  *   to implement in wine.  At the very least we should implement the authorization
- *   API's & gracefully ignore the irrelevant stuff (to a small extent we already do).
+ *   API's & gracefully ignore the irrelevant stuff (to an extent we already do).
  *
  * - Some transports are not yet implemented.  The existing transport implementations
- *   are incomplete and many seem to be buggy
+ *   are incomplete and may be bug-infested.
  * 
  * - The various transports that we do support ought to be supported in a more
- *   object-oriented manner, like in DCE's RPC implementation, instead of cluttering
+ *   object-oriented manner, as in DCE's RPC implementation, instead of cluttering
  *   up the code with conditionals like we do now.
  * 
- * - Data marshalling: So far, only the very beginnings of an implementation
+ * - Data marshalling: So far, only the beginnings of a full implementation
  *   exist in wine.  NDR protocol itself is documented, but the MS API's to
- *   convert data-types in memory into NDR are not.  This is a bit of a challenge,
- *   but it is at the top of Greg's queue and should be improving soon.
+ *   convert data-types in memory into NDR are not.  This is challenging work,
+ *   and has supposedly been "at the top of Greg's queue" for several months now.
  *
  * - ORPC is RPC for OLE; once we have a working RPC framework, we can
  *   use it to implement out-of-process OLE client/server communications.
- *   ATM there is a 100% disconnect between the marshalling in the OLE DLL's
- *   and the marshalling going on here.  This is a good thing, since marshalling
- *   doesn't work yet.  But once it does, obviously there will be the opportunity
- *   to implement out-of-process OLE using wine's rpcrt4 or some derivative.
- *   This may require some collaboration between the RPC workers and the OLE
- *   workers, of course.
+ *   ATM there is maybe a disconnect between the marshalling in the OLE DLL's
+ *   and the marshalling going on here [TODO: well, is there or not?]
  * 
  * - In-source API Documentation, at least for those functions which we have
- *   implemented, but preferably for everything we can document, would be nice.
- *   Some stuff is undocumented by Microsoft and we are guessing how to implement
- *   (in these cases we should document the behavior we implemented, or, if there
- *   is no implementation, at least hazard some kind of guess, and put a few
- *   question marks after it ;) ).  
+ *   implemented, but preferably for everything we can document, would be nice,
+ *   since some of this stuff is quite obscure.
  *
- * - Stubs.  Lots of stuff is defined in Microsoft's headers, including undocumented
- *   stuff.  So let's make a stub-farm and populate it with as many rpcrt4 api's as
- *   we can stand, so people don't get unimplemented function exceptions.
- *
- * - Name services: this part hasn't even been started.
- *
- * - Concurrency: right now I have not tested more than one request at a time;
- *   we are supposed to be able to do this, and to queue requests which exceed the
- *   concurrency limit.
+ * - Name services... [TODO: what about them]
  *
  * - Protocol Towers: Totally unimplemented.... I think.
  *
@@ -85,12 +74,19 @@
  *
  * - Statistics: we are supposed to be keeping various counters.  we aren't.
  *
- * - Connectionless RPC: unimplemented (DNE in win9x so not a top priority)
+ * - Async RPC: Unimplemented.
+ *
+ * - XML/http RPC: Somewhere there's an XML fiend that wants to do this! Betcha
+ *   we could use these as a transport for RPC's across computers without a
+ *   permissions and/or licensing crisis.
  *
- * - XML RPC: Dunno if microsoft does it... but we'd might as well just for kicks.
+ * - The NT "ports" API, aka LPC.  Greg claims this is on his radar.  Might (or
+ *   might not) enable users to get some kind of meaningful result out of
+ *   NT-based native rpcrt4's.  Commonly-used transport for self-to-self RPC's.
  *
- * - ...?  More stuff I haven't thought of.  If you think of more RPC todo's drop me
- *   an e-mail <gmturner007@ameritech.net> or send a patch to wine-patches.
+ * - ...?  More stuff I haven't thought of.  If you think of more RPC todo's
+ *   drop me an e-mail <gmturner007@ameritech.net> or send a patch to the
+ *   wine-patches mailing list.
  */
 
 #include "config.h"