On Thursday, September 18, 2003, at 09:01 AM, noah_mendelsohn@us.ibm.com wrote: > > Maybe Mark's proposal below is indeed the simple 80/20 we seek, but I'm > not completely convinced it goes into enough detail, or that we'll find > consitency in users' needs if we look for such detail. I note also > that > MTOM offers a model, a serialization trick, and an HTTP binding using > the > trick. The requirements for the 3 need not be the same. Consider the > first and last, how about a requirement that says: Just to be clear, I wasn't making a proposal as such, just trying to see if I understood Jacek's wording. > * The MTOM abstract inclusion feature must not preclude the creation > of a > variety of bindings, each of which might support one or more styles of > streaming as needed in various use cases. > > * The HTTP binding provided with MTOM either (a) need not be optimized > for > streaming or ( b) SHOULD provide for accessibity to non-optimzed > envelope > information ahead of the serializations of large binary objects and > SHOULD > further provide for streaming in the case that only one large object > has > been optimized. > > I know these are requirements, not use cases, but that's how I'm > thinking > about it. I like doing this in requirements rather than use cases. Regarding the second requirement, (b) looks good, but I'm still not sure what "streaming" means here. Would this be satisfied by the use of HTTP chunking, for example? Would the fact that MIME requires pre-calculation of a delimiter be considered an impediment to satisfying this requirement? -- Mark Nottingham Principal Technologist Office of the CTO BEA SystemsReceived on Thursday, 18 September 2003 13:15:27 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:41:57 GMT