[WikiReader] file system questions (was: [wikireader]Suggestions for next steps on software)

[Doug Jones]

[snip]
> I like this approach, just remind that as far I see the code and by
> comments of the devs, the kernel implements the bare just enough to
> read files, so I think directories are not implemented at all that's
> why all is on root directory so at least basic hierarchical filesystem
> has to be implemented before we can do this solution. But directories
> will easy the organization of pictures too


Good point.

So two important questions to be answered, before we get any further 
into this:

(1) Has OpenMoko made the policy decision that filenames will be limited 
to 8.3?


(2) How complicated will it be to implement subdirectory support?



Note that only one subdirectory level is really needed to implement what 
has already been suggested.

The current implementation contains 81 files, totaling 4.2GB for the 
English version.  Nearly all of that is in the big wiki data files 
(pedia*).  The other files, the ones you get when you make install, 
comprise 49 files and only 18MB, and most of that is fonts (which are 
often different for different languages).

We could adopt a brain-swap approach:  After bootup, the user selects 
one wiki and then the app switches to the selected subdirectory and 
considers that to be the root until the next cold boot.  All 81 files 
for that particular wiki and language would be in that subdirectory, 
including the big wiki data files and the fonts and the remaining files 
(45 files, only 381KB, and this includes ALL of the executables!)  While 
the single app is running, it would not have to access (or even know 
about) anything outside its current directory, so no filesystem calls 
relating to directory navigation would be needed within that particular 
kernel.elf.  Only the initial wiki selection app (we would have to write 
one) would have to understand subdirectories, and only to one level deep.