View Single Post
Old 02-18-2011, 04:09 PM   #2
chaley
Grand Sorcerer
chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.chaley ought to be getting tired of karma fortunes by now.
 
Posts: 11,741
Karma: 6997045
Join Date: Jan 2010
Location: Notts, England
Device: Kobo Libra 2
Yes, but with caveats.

There are two kinds of plugboards. The first affects copying to a device, changing metadata during the copy process. The second affects databases stored on the device (device_db). The content server could use only the first.

Looking at the content server code, I see that metadata is updated only for EPUB files (library.server.content.py). Today it does not use any plugboard. If a device 'content_server' is added to plugboards, and if content.py is told to use that device, then plugboard transforms would be applied. The code would look a lot like that found in gui2.device._upload_books.

One concern is that today, no other format would acceptable as a plugboard source for the content server. Should the plugboard code be told about that? Hard to say. The current code permits specifying source formats that don't support certain metadata transforms, so the easy answer is 'no, and let the destination do what it can.' However, I can see problems with that answer.
chaley is offline   Reply With Quote