Changes between Version 2 and Version 3 of ApertureDataObjectFile
- Timestamp:
- 10/29/05 12:01:04 (19 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ApertureDataObjectFile
v2 v3 2 2 3 3 Leo: to be used, we can do it as convenient as possible. Meaning, the DataObjectFile has a getMimetype() method which promises to use all tricks that exist. If you don't call getMimetype(), no processing power spilt. If you call it, it guarantees to have done all tricks already (which is very convenient and a useful feaute of the Aperture framework). 4 5 = New-I/O = 6 Some extractors may require extended I/O functionality, like the [http://java.sun.com/j2se/1.5.0/docs/api/java/nio/Buffer.html#position(int) position()] method provided by [http://java.sun.com/j2se/1.5.0/docs/api/java/nio/ByteBuffer.html java.nio.ByteBuffer] and its superclass Buffer. Having a ByteBuffer internally would allow to return new instances of InputStream on each call to getInputStream(). Also, we may add (when needed) a getByteBuffer() method that returns the raw data. 4 7 5 8 … … 28 31 * The returned InputStream is required to support marking (markSupported() 29 32 * returns true). Calling this method multiple times may references to 30 * one-and-the-same InputStream instance. Care should therefore be taken to mark 31 * and reset the stream when the stream's content is to be read again later. 33 * one-and-the-same InputStream instance. The position of this stream will 34 * be at the beginning, after getContent() is called. Thisis achieved through 35 * an internal New-IO Channel from which the Stream is fed. 32 36 * 33 37 * @return An InputStream from which the content of the data object can be read. … … 40 44 * times in its entirety, making the mark-and-reset procedure difficult to work, 41 45 * and that it better should cache the entire contents. 46 * The internal caching should be implemented using a New-IO ByteBuffer. 42 47 * @throws IOException when an IOException occured during caching of the content. 43 48 */