[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Portable Text I/O using OOC library API
- To: ooc-list@informatik.uni-kl.de
- Subject: Portable Text I/O using OOC library API
- From: Ian Rae <ianrae@istar.ca>
- Date: Tue, 27 Jan 1998 23:05:54 -0500
- MMDF-Warning: Parse error in original version of preceding line at news.uni-kl.de
Apologies for the delay -- major power outages here over the last few
weeks due to an ice storm.
What I'm looking to do is create a text i/o library that will be available
on all Oberons: V4, System 3, Black Box, POW, and OOC.
This library will support reading & writing of plaintext on various data
locations -- ASCII text files, Oberon text documents, text in current
"frame", etc. The benefit of this library is that Oberon utilities such as
COCO or grep can be written once and used throughout the Oberon
community.
I would like to use the text i/o portion of the OOC library as the API.
This library would use the file prefix "OOC" to distinguish its modules
and identify its heritage.
Module OOCChannel
-define the abstract types Channel, Reader, Writer
Module OOCFiles
-define the abstract classes File, Reader, and Writer that are extensions
of their counterparts in OOCChannel
-define hidden concrete extensions of File, Reader, and Writer for the
following types of files:
-ASCII text files. ie. native OS text files
-text documents of the target Oberon system. For instance,
V4 Text files, BlackBox .ODC files, etc.
(Implementation would use the highest level classes available
in the target Oberon system. eg Texts in V4, etc)
-locator procedures would create a File object appropriate to the
type of file being accessed.
Module OOCTexts
-define the abstract classes for accessing plaintext in the Text
object of the target Oberon system. eg. TextModels in BlackBox,
Text in V4, etc
-these classes (Text, Reader, and Writer) would be concrete extensions
of their counterparts in Channel
-locators will be available to "open" the current frame, or the selected
text, etc
Modules OOCTextRider and OOCBinaryRider
-define mapper classes that can connect to any OOCChannel
-should be usable with only minor changes from OOC library version
Module OOCProgramArgs and OOCStdChannels
-I'm not sure if these notions exist in most Oberon system?
Module OOCLogs
-support writing to the Log via a OOCChannel
Questions
--------------
1. Do I need your permission to use portions of the OOC library?
I would be publishing my library under GPL or whatever public
domain approach makes sense.
Answers to Previous Post
--------------------------------------
Michael van Acken wrote:
>One fundamental question: As you said the OOC io routines fit youur
>needs. Does that mean that you simply want to extent them, to support
>OberonSystem files or do you want to build a layer on top of the io
>implementation of OOC. If you plan the second, isn't is possibly better
>to extent the OOC io routines? I currently don't have arguments for
>that (in fact I have some against it), but I feel the io ystem of OOC
>might gain more from the second aproach. I also don't like to build
>multiple layers on code, since the OOC io system is already a layer on
>the C/POSIX io system.
I plan to extend the OOC io routines. This is intended to be a very
thin layer that doesn't re-implement the existing io functionality in
Oberon systems. Yes, it is another layer but the goal here is
portability not performance (although I don't expect a large
overhead in this "layer").
--Ian