View Single Post
Old 08-07-2012, 10:20 PM   #70
NiLuJe
BLAM!
NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.
 
NiLuJe's Avatar
 
Posts: 13,477
Karma: 26012492
Join Date: Jun 2010
Location: Paris, France
Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E
I finally had time to start playing with the Calibre import/export! It's pretty cool

A quick question about the import: Does it reset the visibility/parent(s) of *existing* collections?

Basically, I plan to do a relatively simple setup:
all the genres nested into a Genres collections, all the authors nested in an Authors collection, etc. Right now it's faked on my K3 by using a crapload of toplevel collections, with a specific prefix/suffix for genres, another for authors, etc.

I was looking at how to handle this simple nesting automatically, and promptly realized that it was impossible without implementing a clunky prefix/suffix detection in the Kindlet [ie. all the stuff that matches '^(>)(.*?)(<)$' (prefix > / suffix <) is hidden in Home, and goes into the collection 'Authors', etc.].

Another idea would be to tweak the JSON format used, but I'm not sure there's enough info to match the correct parent collection at the import stage. From what I gather, it's just a query against the name? So, yeah, maybe doable, but I'm not sure how exactly to coax the json data into an acceptable/parseable format while preserving the nesting... And we'd need to tweak the Calibre plugin to handle this 'new' format, too.

That leaves me with this question. If it doesn't touch visiblity/nesting on import, I can probably live with it, it means that I'll only have to tweak nesting/visibility manually each time a *new* collection is added, not for everything at every import, which would be bad .

Apart from that, a few small bugs:

* When the cdeKey begins with *, it means that there's no ASIN (or fake UUID as ASIN) in the headers of the book, and the key was derived from the sha1sum of the absolute path of the file. That changes the format used in the legacy json file. It's just 'cdeKey', instead of '#cdeKey^cdeType'. (Right now it's exporting stuff as '#*sha1sum^EBOK' instead of just '*sha1sum').

* The lastAccess field is faked in the exports, but that's not a huge deal .

* In the same 'no ASIN' vein, in the case of Kindlets, the cdeKey is NULL for custom stuff. They don't get exported. I don't think there's anything we can do on that front (well, except making Kindlet authors put a fake UUID in the Amazon-ASIN field of their Kindlet Manifest), just mentioning it . (They used the same *sha1sum trick as for books on previous firmwares, so custom Kindlets could be managed via Calibre).

Last edited by NiLuJe; 08-07-2012 at 11:30 PM.
NiLuJe is offline   Reply With Quote