Apple-2-Tools/nulib2
1
0
Fork 0
mirror of https://github.com/fadden/nulib2.git synced 2024-12-29 15:29:16 +00:00
Code Issues Projects Releases Wiki Activity

Update design note

Browse Source
This commit is contained in:
Andy McFadden 2015-01-09 14:52:22 -08:00
parent 9e761fbd66
commit 8251e41ddb
1 changed files with 14 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
nufxlibapi.htm
View File

@ -1862,6 +1862,7 @@ NufxLib is intended for manipulating archives, not compressing streams of data,
the added flexibility did not justify the cost.  (I'm becoming less certain the added flexibility did not justify the cost.  (I'm becoming less certain
of that as time goes by.  If I had it all to do again, I probably would use of that as time goes by.  If I had it all to do again, I probably would use
the functional interface for all file accesses.)</p> the functional interface for all file accesses.)</p>
<p>It might have been useful to allow read/write/seek hooks for the archive <p>It might have been useful to allow read/write/seek hooks for the archive
itself.&nbsp; The current architecture prevents you from processing an archive itself.&nbsp; The current architecture prevents you from processing an archive
that has been loaded into memory, unless you have memory-based FILE* streams in your that has been loaded into memory, unless you have memory-based FILE* streams in your
@ -1872,17 +1873,19 @@ until I wanted to set a parameter that affected the way open works (the
junk-skipping feature).&nbsp; Creating the structure in a separate call before junk-skipping feature).&nbsp; Creating the structure in a separate call before
the &quot;open&quot; would the &quot;open&quot; would
have been better.</p> have been better.</p>
<p>It might, for portability reasons, have been better to require a &quot;create
file&quot; callback.&nbsp; This would offload most of the system-dependent stuff <p>The biggest problem with NufxLib is that it tries to do too much. A much
in FileIO.c onto the application.&nbsp; I chose not to do this because I felt it larger share of the work should have been done in NuLib2. The easiest way to
moved too much of the work out of NufxLib and into the hands of the see this is to look at a feature like the built-in end-of-line conversion. It's
developer.&nbsp; Requiring the application to deal with the &quot;OnlyUpdateOlder&quot; certainly handy to have, but applications like NuLib2 and CiderPress work with
and &quot;HandleExisting&quot; flags seemed excessive, and if there really are more than one type of archive, which means we either won't support EOL conversions
wide variants in the way files are created and modification dates are tested, (e.g. NuLib2 doesn't convert when extracting from BNY) or we have to
then we might as well solve the problem once and for all in the library instead reimplement it in the app anyway (e.g. CiderPress has a complete copy of the NufxLib
of requiring every application to solve it for themselves.&nbsp; (I could, of implementation). Nearly everything relating to files should have been done by
course, provide sample code for several different platforms, but sample code the application, with NufxLib using a file descriptor or memory buffer to
tends to suffer from bit rot.)</p> access the archive, and app-supplied read/write functions to handle compressed
data.</p>
<p>There is no real support for GS/OS option lists.&nbsp; The only place you'd <p>There is no real support for GS/OS option lists.&nbsp; The only place you'd
ever want to add these is on a IIgs, and I find it unlikely that NufxLib will ever want to add these is on a IIgs, and I find it unlikely that NufxLib will
edge out GS/ShrinkIt as the preferred archiver.&nbsp; (Besides, I question their edge out GS/ShrinkIt as the preferred archiver.&nbsp; (Besides, I question their