On 10/24/08, Dan Becker <[EMAIL PROTECTED]> wrote: > I'd like to follow up and further refine some ideas about data binding > improvements. Much of this was published by Raymond on the wiki road map > page [1] and on earlier dev list discussions [2]. > > I am especially interested in the areas regarding MIME type and binary > data support given here. I think these 3 facets are related. > - Use MIME types to model the databinding ids (for example, application/xml, > application/x-java-serialized-object, image/jpeg) > - Support MIME based binary data types (incuding the xmime extensions in > WSDL/XSD) > - Support annotations of a java type (for example, an InputStream can be > used to contain different formats of data) to further constrain the data > type (We could use the JAXB annotation for this purpose) > > Earlier this week I put together a customer scenario that I thought > would benefit from this kind of feature. I imagined an auto insurance > claim business service where customers could submit claims (simple Java > beans with info) along with digital images of receipts. I thought the > images could be provided as an InputStream or byte[]. Something like this: > <service name="ClaimService"> > <interface.java interface="insurance.ClaimService" /> > <binding.ws uri="http://localhost:8080/insurance/ClaimService"/> > > </service> > And the claim service would be something like this: > @Remotable > public interface ClaimService { > boolean submit( Claim claim, InputStream [] receiptImages ); > } > > Here is where I run into a junction, and I would like to open up the > discussion to other Tuscany developers. Ideally I would like the > interface to be generic, so as not to constrain the data to one image > type. Allow JPGs, GIFs, PNGs, and future image types. On the other hand, > I would not like to saddle clients with lots of digging, testing, and > formatting work to fit into a more specific data type on the interface. > MIME types seem a useful means of conveying what is in the binary > InputStream. However, I'd like to know the best place to specify this. > Put it on the service interface? As an extra method input? As a generic? > Some other form of annotation? > > This same sort of content discussion also applies to Strings. What is in > that String you are passing? Text? HTML? XML? Other? How should one > specify it so that clients are services don't have to do lots of digging > and testing on the String? > > What do users think would be an improvement over passing unlabeled blobs > (InputStream, byte [], String, etc.) around?
In general, to understand a MIME encoded document, a single type string is not sufficient. An image typed image/png but this may be transfer encoded BASE64, quoted-printable, native etc. To decode without magic, it's neccessary to allow multiple MIME headers. IMHO it would therefore be better to allow general text based meta data headers Robert > > [1] http://cwiki.apache.org/confluence/x/oU8B > [2] http://markmail.org/message/4iazlvo23qq3tho4 > > -- > Thanks, Dan Becker >
