alexandria and ebboks?

[atenrok]

hello,

Having quite substantial number of electronic books on my harddrive, I've been looking fro some kind of ebook manager for linux, but so far did not find anything that would suit me (not surprising, considering there are only two projects of that kind available for linux now: eKitaab and calibre). I found alexandria instead, which appears to be a book library manager and it does all I need, except it is for another kinds of books. I'm not sure uhm... how does this correlate with the author's roadmap, but it is probably not too difficult to add another couple records to the properties of the book in the database, which would hold a path to the local file and the checksum. This would make alexandria a nice ebook manager. And when I'm saying "not too difficult" I don't mean myself, because I'm ruby-illiterate, but for somebody who knows stuff? Or maybe this topic has been discussed around here already?

[Cathal Mc Ginley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adding support for cataloguing e-books has been discussed before, but
no real progress has been made on the topic.

As I've been saying a lot recently, adding e-book support directly to
Alexandria is not going to happen soon - the code would need
substantial redesign to support such a change.

However, substantial *new* design is happening independently of the
main Alexandria project. I have allowed for the possibility of e-books
in the design of Palatina (the not-even-remotely-ready-for-users
Alexandria replacement). So any feedback you can give would be helpful
in shaping the code which will eventually (i.e. months from now) be
wrapped back into Alexandria.

The properties you mention for e-books are:
 * file path
 * checksum

I can also immediately think of:
 * file format (e.g. PRC, PDF, FB2...)
 * file size
 * URL (if the e-book is available online)
 * DOI (Digital Object Identifier - akin to ISBN for electronic
   documents)

I've already updated the Palatina wiki with your suggestions:
http://palatina.gnostai.org/wiki/BookDataRequirements

Are there any other properties that would be particularly useful?
Should the Alexandria GUI have any extra features or behaviour to
support useful handling of electronic texts?

   -   Cathal.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: GnuPT 2.6.2.1 by EQUIPMENTE.DE

iEYEARECAAYFAkoV9lkACgkQfMAUnRdb+8rabgCgyT7NGOX/t4dzR10beRyEmt+b
9TQAmgL47nCQ8451Ed9Jgv6u8i+xH8Td
=lUzc
-----END PGP SIGNATURE-----
_______________________________________________
Alexandria-list mailing list
Alexandria-list@...
http://rubyforge.org/mailman/listinfo/alexandria-list

[atenrok]

Cathal,

Cathal Mc Ginley wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Adding support for cataloguing e-books has been discussed before, but
no real progress has been made on the topic.

As I've been saying a lot recently, adding e-book support directly to
Alexandria is not going to happen soon - the code would need
substantial redesign to support such a change.

However, substantial *new* design is happening independently of the
main Alexandria project. I have allowed for the possibility of e-books
in the design of Palatina (the not-even-remotely-ready-for-users
Alexandria replacement). So any feedback you can give would be helpful
in shaping the code which will eventually (i.e. months from now) be
wrapped back into Alexandria.

I'm really happy to read this, especially realizing that you care about potential user suggestions  before implementing the features.

Cathal Mc Ginley wrote:

The properties you mention for e-books are:
 * file path

yes. And the main issue here is that the library manager application should not try change the location of the file. You can allow yourself to rename the file to some kind of comprehensive name (like author-year-isbn, or whatever you come up with) but if the user has its files arranged into some kind of catalog structure -- that should be intact. I emphasize that because the author of calibe, mentioned above, decided that application should organize the files for the user.

 * checksum

this one, obviously should be used to keep track of duplicates and fixing the database of the path to the file was changed outside out alexandria.

I can also immediately think of:
 * file format (e.g. PRC, PDF, FB2...)
 * file size
 * URL (if the e-book is available online)
 * DOI (Digital Object Identifier - akin to ISBN for electronic
   documents)

very nice, taking into account that tags, notes and rating is implemented in alexandria, this pretty much makes the list complete. The suggestion here would be to implement different icons for corresponding formats, so these are easily identifiable in the list. Although, if you add the column indicating the file format, then the icons are obsolete to my mind.

Also here is the question, is the "genre" field useful or should user rely on tags?

Are there any other properties that would be particularly useful?
Should the Alexandria GUI have any extra features or behaviour to
support useful handling of electronic texts?

when it comes to handling, these days linux pretty much has all the applications needed to handle most of the formats available on the market. In case there's no reader available -- there is always  a converter. Since not all of these are defined in mime-types you probably should let the user choose the corresponding reader for every file-format somewhere in the preferences dialog.

Possibility to rescan the library (the directory with ebooks) in case  the user has added some new books. In case the new book is detected, it is offered to be added to the database (ask the user to fill the record information). There  should be way to initiate the "rescan" manually, as well as schedule the interval for it.

I don't particularly care about the next one, but I suspect that some users might request these later, so you might start thinking about that ahead of time.

1. format convertors, perhaps you should think about interface to specify those the same way as the readers.
2. support for various kinds of hardware ebook readers. Since you cant own them all, I would suggest implementing a plugin interface and let somebody else write corresponding plugins.

good luck,
and keep up a nice job