Changes between Version 8 and Version 9 of ApertureDiscussion

Timestamp:

07/04/06 11:15:35 (18 years ago)

Author:

sauermann

Comment:

--

ApertureDiscussion

@@ +1 @@
+[[PageOutline]]
 = Open Issues in Aperture =
+
+== java.io.File-Based Exctractors ==
+
+We have some code-pieces (like MP3 extraction) that do not work on inputstreams but only on files. 
+
+There are different approaches to solve that:
+=== ideaA: rewrite all File-Based extractors using inputstream ===
+Somebody writes new Extractors implementing the InputStream-based extraction interface.
+ * issue: these have to be written completly new?
+  * idea: have somebody else write them.
+ * pro: They are probably more performant than the existing ones and have less overhead
+ * con: they have to be written new
+
+=== ideaB: add a new  method to Extractor, passing in the file as argument ===
+This is the existing Method:
+{{{extract(URI id, InputStream stream, Charset charset,
+                        String mimeType, RDFContainer result)}}}
+We could add a new one to the Interface Extractor:
+{{{extract(URI id, File file, Charset charset,
+                        String mimeType, RDFContainer result)}}}
+
+ * pro: no new interface
+ * issue: looking at the Interface, it is not clear what method to use and what is implemented. Should I call first the method with InputStream and see if it fails? hm
+ * issue: this depends on ideaC
+
+=== ideaB1: create a new Interface FileExtractor, passing in the file as argument ===
+Create a new Interface FileExtractor, that implements only one method. Declare that this interface should only be used in cases, when there is no InputStream-based extraction library available and say that this FileExtractor is mediocre to the normal Extractor.
+{{{extract(URI id, File file, Charset charset,
+                        String mimeType, RDFContainer result)}}}
+
+ * pro: developers can determine which kind of Extractor they face and which method to call
+ * con: we need a new registry for FileExtractors
+ * issue: this depends on ideaC
+
+=== ideaC: Add a new method getFile() to FileDataObject ==)
+Add a new method getFile(), returning a file, to FileDataObject. This is easily implemented on File-based data objects (crawling local file system). For remote FileDataObjects, the method will be implemented using a buffering of the InputStream. ideaB and ideaB1 depend on this getFile() method.
+
+ * pro: optimizes the implementation for file-system-crawler
+ * issue: on some constellations (crawling remote MP3s), there will only be FileExtractors and everything will be buffered on local harddisk
+   * idea: this is not so much an issue, the benefit for the end user of having more data outweights it
 
 == DataOpener.open(uri) ==