[bookcourier] Re: Transfer Tool Problem
- From: "Graham Lewis [gjl]" <gjl@xxxxxxxxxx>
- To: "bookcourier@xxxxxxxxxxxxx" <bookcourier@xxxxxxxxxxxxx>
- Date: Sun, 5 Sep 2010 11:22:41 +0100
Deborah,
That does make sense. I had assumed that creating filename
from the contents of the file was a design decision, rather than a compromise.
I have always thought that Springer did an amazing job with the Bookccourier,
providing reliability and plain common sense design, well beyond what a small
business should be able to achieve. There is not anything out thatere that can
touch the bookcourier for this. I have a number of newer gadgets that do
similar things, but still rely heavily on the bookcourier for day-to-day text
reading. It would be great if this could be released as an open source
software and hardware project akin to the mp3 player project that you are
involved in. Sure the bookcourier was a great little mp3 plater too, but its
unique strengths were in the plain text reading aspect.
Graham Lewis
Co-ordinator, CDSAP.
From: bookcourier-bounce@xxxxxxxxxxxxx
[mailto:bookcourier-bounce@xxxxxxxxxxxxx] On Behalf Of Deborah Armstrong
Sent: 04 September 2010 21:12
To: bookcourier@xxxxxxxxxxxxx
Subject: [bookcourier] Re: Transfer Tool Problem
>I have never really understood the advantage of using the first line of each
>file as its filename in bookcourier. I really wish it would just use the
>filename it already has on the computer.
That would have been a better interface design but there are some limitations
in traversing a Fat32 file system, that I never understood until I had to port
the source code for the firmware of an Mp3 player from one compiler to another.
My husband had designed this open-source MP3 player hardware, but he'd written
its firmware usingan expensive compiler that belong to his employer. So he got
me as a honey-do project to fix his source code so that it would compile on an
open-source compiler called sdcc. Anyway, I'm not the world's greatest
programmer, but I was free, being a wife and all.
So I learned pretty quick that dealing with these file systems is involved, and
I believe when they did their latest design of the transfer tool that they
started using the short 8-3 filenaming convention to make the book courier
itself open files faster. The problem was though that file names ended up being
called BC0000037.IDX and such, and the book's actual title stopped being part
of the filename. So the transfer tool has to open the file to figure out what
the book title is. It might have done that before, but with smaller cards we
didn't load them up with so many files and folders.
Windows can zip through a mountain of files and folders because it's typically
running on a fast Pentium chip. The chip in thebookcourier had to be cheap
enough that the bc could be sold for a reasonable price, and that meant it was
slow, so the programmer of the bc firmware had to work harder to ensure that
files were set up on the BC in such a way that navigation between them was
responsive.
They made changes to support 4GB cards, and that caused them to make
compromises that later showed up in poor performance of the transfer tool. And
they probably can't justify the time required to perfect the transfer tool
software and still remain in business.
It's just a guess on my part but I used to have a small business and I know how
these tradeoffs can trap you.
(For the curious, the MP3 player is at:
http://www.sparetimegizmos.com/Hardware/MP3_Player.htm
--Debee
Other related posts:
