[Alexandria-list] [Fwd: Re: Alexandria SVN crash when loading library]

[Ian Davey]

Cathal Mc Ginley wrote:
> Any ideas for increased functionality are most welcome. (I'm not sure
> what "reading management" is though.) When I reorganize the
> documentation after the upcoming stop-gap release, there should be some
> kind of central wish-list. Perhaps a wiki would be best for that kind of
> thing.
>
>   
Including read dates, (optional) start and finish dates for a book, page 
counts etc. So you can query to get a list of books read in a year, how 
many you read, how many pages etc. Also organisation for unread books, 
goal lists etc. I'm on a book list filled with people with to read piles 
that often top a few hundred books.  So it's merely features to make 
Alexandria more useful to people who read a lot, extending it beyond a 
mere cataloguing application. So it's about the metadata you add to 
books rather than the automatically applied information from Amazon etc. 
It will need to be optional and keep out of the way for people who do 
want Alexandria to be just a cataloguing application, but it would 
certainly make it more useful for me so I can get rid of my books 
spreadsheet.

> I believe the slowness was tracked down (I saw a reference to it on the
> list archive): it's apparrently largely attributable to resizing the
> image thumbnails on load, rather than the file-based storage of book
> data.
>   
Yeah I did some digging in to it a while back, eliminated the yaml 
backend as the cause and was working on some code to automatically 
resize the image down to the maximum size. To see if that reduced the 
time for the image resize, due to the resize code having to load 
potentially hundreds of megabytes of data from disk to create the 
thumbnails.

I have been considering a few ideas about how to remove the problem in a 
different way, splitting the display into pages that you scroll through 
with back and forward icons. With a dynamic filter to narrow down what 
is displayed. As I'm not sure a display with 1000 icons is necessarily 
optimal, no matter how quickly it loads. It will then be easily to port 
to smaller more memory constrained environments like the N800. The key 
information is what can be displayed on the screen at any one time, so a 
combination of paging and filtering should make it more usable. That's 
just my view though, not sure how other people feel about that.

ian.