snichol 2002/10/11 08:42:43
Modified: . TODO
Log:
Removed the 2.1 stuff and anything that was already done. Added notes
where things seem at least partially done. Add all my TODOs and
unsupported SOAP spec items as wish list.
Revision Changes Path
1.8 +52 -22 xml-soap/TODO
Index: TODO
===================================================================
RCS file: /home/cvs/xml-soap/TODO,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- TODO 25 Jun 2002 05:16:26 -0000 1.7
+++ TODO 11 Oct 2002 15:42:43 -0000 1.8
@@ -1,25 +1,5 @@
Apache SOAP Project To-Do List:
-
-V2.1 ToDo List:
-===============
-
-Owner(s) Item
--------- ---------------------------------------------------------------
-
-
-
-V2.1 Wish List:
-===============
-(items can move to ToDo List if there's an owner):
-
-Owner Item
--------- ---------------------------------------------------------------
-? Support HTTP Basic Authentication
-? Support HTTP Sessions
-
-
-
General Wish List:
==================
@@ -39,7 +19,8 @@
- add a setHeader(s) method to SOAPTransport to allow a client to set
transport headers. Currently we allow getting at response headers, but
- not to set outgoing headers. Ouch.
+ not to set outgoing headers. Ouch. Note that SOAPHTTPConnection allows
+ headers to be specified in the send method.
- change the APIs to enable one to use this code to do just one directional
messaging instead of only RPCs. The code already does support one
@@ -50,7 +31,8 @@
real store; such as a JDBC store. Currently the stuff is written out
to a file via serialization. An abstraction layer needs to be put on
to allow easy integration with hosting app server's persistency
- mechanism.
+ mechanism. This work appears to have at least started, as there is
+ also a configuration manager that reads/writes XML.
- consider and understand the role of servlet scopes in lifecycle mgmt of
objects. We currently allow the deployer of a service to indicate the
@@ -82,3 +64,51 @@
side. The purpose is to use a session scoped service and to see how to
implement the cookies stuff so that the right thing happens.
+- support DIME and WS-Attachments
+
+- mirror Axis XML <--> Java mappings more closely
+
+- optional logging of requests and/or maintenance of request statistics
+
+- follow HTTP redirects on the client
+
+- improve the messaging sample to actually read the envelope (as instruction
+ to others on how to do this)
+
+- allow config files to be resources so they can be packed in the war in a
+ portable manner
+
+- one-way messaging Microsoft style, in which the server responds with an
+ HTTP "202 Accepted" status upon receipt of the request *before* actually
+ invoking the method to handle it; this would be a deployment descriptor
+ option on the server
+
+- schema validation option with a way to specify schemas to possibly
+ validate against
+
+All of the things listed in intro.html as not supported:
+
+- multiple encoding styles in the encodingStyle attribute
+ (see section 4.1.1 of the spec)
+
+- actor attribute and SOAP intermediaries (4.2.2)
+
+- complete mustUnderstand attribute behavior - only supports checking
+ for and rejecting requests that require mustUnderstand
+ checking (4.2.3)
+
+- element typing by having the name of the element bear a definite
+ relation to the type, that type then determinable from a schema,
+ except for elements named SOAP-ENC:Array (5.1 rule 2c)
+
+- deserialization of null values for XML schema types
+ that are mapped to primitive Java types (5.1 rule 9)
+
+- the complete set of XML schema simple types (5.2)
+
+- multi-dimensional arrays (5.4.2), arrays of arrays (5.4.2),
+ partially transmitted arrays (5.4.2.1), sparse arrays (5.4.2.2)
+
+- root attribute (5.6)
+
+- input/output and output parameters
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
