On Mon, 2004-01-12 at 17:14, Mark R. Diggory wrote: > > Noel J. Bergman wrote: > > > Mark R. Diggory asked: > > > > > >> Shouldn't [mime] be dependent on JAF? > > > > > > Why? > > > > --- Noel > > > > For a standardized cross platform means of resolving a streams mime-type > to an appropriate Object (File, String, XML, etc). I know there are > issues with how its used by JavaMail, but is this just poor > implementation in JavaMail or a shortcoming in JAF specifically? From > earlier references, JavaMail is observed to not be capable of handling > large attachments (Multipart MIME SMTP) because of its "in memory" > approach and because JavaMail throws exceptions when it can determine > the mimetype of the data. Is this a fault in JavaMail or JAF. If its > just JavaMail than JAF may/will still be of useful benefit. > > From Sun's site: > > > With the JavaBeans Activation Framework standard extension, > > developers who use Java technology can take advantage of standard > > services to determine the type of an arbitrary piece of data, > > encapsulate access to it, discover the operations available on it, > > and to instantiate the appropriate bean to perform said operation(s). > > For example, if a browser obtained a JPEG image, this framework would > > enable the browser to identify that stream of data as an JPEG image, > > and from that type, the browser could locate and instantiate an > > object that could manipulate, or view that image. > > -Mark
I tried to use JavaMail/JAF for the ebxml stuff I was doing, and gave up. I think it is one of the nastiest Java APIs in existence, regardless of whether the implementation is also broken. It's really trying to do a very simple task; given a mime type and a block of data, instantiate an object to handle the data. Quite how they ended up with something so baroque I don't know. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
