Changes between Version 1 and Version 2 of ApertureOpeningDocuments

Timestamp:

10/12/05 14:06:28 (19 years ago)

Author:

anonymous

Comment:

--

ApertureOpeningDocuments

@@ -1 +1 @@
 = Opening Documents =
 
-Besides crawling resources, we should also be able to open them.
+Besides crawling resources, we should also be able to open them in their default viewer.
 
-At first this may look like a job for the DataAccessor?, which after all has knowledge about the details of the physical source.
+At first this may look like a job for the !DataAccessor, which after all has knowledge about how to load the stream from the physical source.
 
-On second thought, I believe that for the opening of files you need some other service, parallel to DataAccessor?, that is also scheme-specific and that takes care of opening the files. Reasons:
+On second thought, I believe that for the opening of files you need some other service, parallel to !DataAccessor, that is also scheme-specific and that takes care of opening the files. Reasons:
 
-- DataAccessors? actually retrieve the files, which is not necessary for some file openers. For example, for opening a local file you can instruct Windows to do just that. Similarly, a web page can be retrieved and shown by a webbrowser, there is no need for us to retrieve the contents and feed it to the browser.
+ * !DataAccessors actually retrieve the files/webpages/..., which is often not necessary for some !DataObject openers. For example, for opening a local file you can instruct Windows to do just that. Similarly, a web page can be retrieved and shown by a web browser, there is no need for us to retrieve the contents and feed it to the browser.
 
-- There may be several alternative ways of opening a resource. For example, the java.net JDIC project contains functionality for opening files and webpages, whereas we have our own classes to do that.
+ * There may be several alternative ways of opening a resource. For example, the java.net JDIC project contains functionality for opening files and webpages, we have our own classes to do that, there may be customer-specific implementations, etc.
 
 This may be a good reason to decouple this functionality from the DataAccessor? and run it in parallel.