Re: Suggestions for FILEMAN.E

new topic     » topic index » view thread      » older message » newer message

In any sitituation that you expect a file format to change several times.
It is highly suggested that you Start with version numbers.  They will
allow you detect the version and load it even if it is an old type.
You could then convert it to the new type and begin using it that way.
But I highly suggest implementing version #'s to enable the ability
for backwards compatibility.
I know Old stuff is usually thrown out because it is SLOW.
But for those that grow accustom to using something and then
get abrubtly changed with out any backwards compatibility or
conversion availble get truley STUCK.  For them.  They understand
either SLOW or NO.  I promise you they prefer SLOW to NO.
I've rambled enough.  My point is that with FileFormats version
detection is easy to start & maintain.  All version that don't have
it suffer the inability to be detected as valid formats but once
it has been implemented all versions from then own can be detected
and USED.

        Lucius L. Hilley III
-- This message maybe distrubuted freely.  It is Freeware and
-- requires no contributions.  However Donations are welcome.  :)

On Fri, 19 Feb 1999 16:53:56 -0500, Brian Jackson <bjackson at PRINTINGINC.COM>
wrote:

>>        Indexing is a definite need.  Also may I suggest the ability
>>to LOCK a Record or File, for multi-user support?
>
>Hugo Rozas posted LOCK.E to the contributions page a while back.  I've only
>looked at it briefly, but I think it should work well with fileman.  Before
>I get that far, I'd like to lock in a particular file format and get some
>basic indexing done.  Right now, nobody is going to go out and use FILEMAN
>in a program, because the filespecs could (and probably will)change several
>more times before they become final.
>
>Brian Jackson

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu