Re: data access functions

Jean-Pierre Prost (jpprost@watson.ibm.com)
Thu, 13 Mar 1997 12:15:58 -0400

Sam Fineberg writes:
I think the real issue is whether or not we want to support the writing
of partial filetypes. I don't see any reason why sane programs would
want to read and write partial filetypes. The original reason for
reading/writing partial filetypes was to use filetypes to emulate Vesta
file views, i.e., to control file striping. Using filetypes in this way
may improve performance on some systems, but the performance improvement
will be totally non-portable.

The example above is another reason for reading partial filetypes, however,
I do not think that this case is likely. If the system you are using
really has too little memory to load entire filetypes then the filetype
should be redefined or a simple "least common denominator" filetype should
be used.

I.e., why not use the following filetype:

|--------------------|.............|
contiguous hole

Or, if you don't have enough memory to read a "contiguous" region, why not
just use:

|---------|
contiguous

There is no real benefit to having holes in filetypes if you aren't
accessing filetypes that span the hole.

Now, if we can agree to make the change to prohibit accessing partial
filetypes, eliminating the etype isn't really a change. There were only
three reasons why we initially created the etype:

1. There needed to be a common type signature between the buftype and the
filetype

- this is now just explicitly mandated.

2. We needed a data size independent way to specify absolute file offsets
(i.e., we didn't want to specify offsets in bytes)

- this need was eliminated a long time ago when we eliminated
absolute offsets

3. We needed a way to express offsets in to the middle of a filetype

- eliminated by this change

So, if we do decide to make this change, then eliminating etypes is a
necessity because they will no longer serve any purpose.

************************
Unless application writers claim that they really need to get access to
partial filetypes, I think removing the etype would
make much sense, simplifying both the interface (making things simpler to
the users), and implementations.
I agree with John that we should not rush into making such a decision, but
I do not see any problem with removing
etypes, besides the fact that we remove some functionality to the
interface. Now if most users agree to say that this
functionality is not to commonly used, I think the change would be
beneficial.
Assuming we adopt this approach, offsets would be expressed in number of
filetypes.

Jean-Pierre

##########################################
Jean-Pierre Prost
IBM T.J. Watson Research Center
PO Box 218
Yorktown Heights, NY 10598
USA
Phone: (914) 945 3225 - Fax: (914) 945 2141
Lotus Notes: Jean-Pierre Prost @ IBM Research
Internet: jpprost@watson.ibm.com
URL: http://www.research.ibm.com/people/p/prost/
##########################################