Kindle specific view for the Content Server

[terwey]

Hi,

this is still a Work in Progress but I wanted to get some feedback on this before.
This is a Kindle specific view for the Calibre Content Server because the mobile view was sadly a bit of a mess on my Kindle.

I started by taking the normal mobile.py and duplicate it to kindle.py and work my way from there.

On top of that I've decided to filter away formats that the Kindle cannot show and just display the one's it can.
It starts by doing a format:mobi OR format:azw3 search query and then afterwards on URL generation for the Download again only showing the relevant formats.

I've also made it possible to directly search for an Author, Tag or Series through the use of normal hyperlinks.
And because sometimes you want to see a Summary (but not always) this is Toggled through a simple Javascript command (which the Kindle supports! hooray!)

I'd love to hear some feedback, I haven't done Python in a while so don't go completely bonkers on me ;)

[kovidgoyal]

Some comments:

1. What Kindle are you targeting. The different generations of the eink kindles have different browsers. You also probably want to exclude Fire's, since the normal content server view works fairly well on them.

2. Kindles support more formats that just mobi and azw3 -- pdf, azw, azw4 and so on, see kindle/driver.py

3. Rather than define a whole new module with lots of duplicated code, why not just specialize the markup returned by the existing mobile view if the browser identifies itself as a Kindle.

[terwey]

@kovidgoyal thanks for the comments

1. I developed it using my Kindle Paperwhite. I did not focus yet on excluding targets because it's of course still a development process which has to be reviewed :) I sadly do not have access to a Kindle Fire to see if that would be detected as the same device.

2. Alright, that's a good place to take a look. I just found these 2 formats to be compatible according to Wikipedia

3. I've thought of this, but this would've required a lot more coding.

I would personally prefer to separate the representation layer from the logic and just have a normal template. I saw in the code that some parts of the Content Server already has this but this part doesn't yet.
I don't know if this is on the roadmap...

Some ideas from the Kindle view would be great I think to have in the Mobile view like the hyperlinks on the Author, tags, pre-filtered formats depending on the device browsing the page.
This however, would require more knowledge about the Calibre codebase.
I was able to figure out some things and hack in some others but it's not necessary clean code.

Maybe it's an idea to write down some ideas what else we (the users) would like to see so maybe we can figure out a way to implement this properly? It luckily didn't take me weeks to hack this together so a clean approach for a stable release would be 👍 for me

[kovidgoyal]

A general refactoring of the content server is on my TODO list, see http://www.mobileread.com/forums/showthread.php?t=219642

As part of that, the server will stop using server side html generation and instead use some kind of client side templating library along with the ajax endpoints in ajax.py. Hopefully, when this gets done, there will not need to be a mobile.py at all, and we can use a responsive/adaptive/whatever-the-current-buzzword is single design for all screen sizes.

In the meantime if you wish to make relatively small improvements to mobile.py, you are welcome to do so.

Regarding 3) I dont see why it would be a lot more code. Can you elaborate?

[terwey]

As part of that, the server will stop using server side html generation and instead use some kind of client side templating library along with the ajax endpoints in ajax.py. Hopefully, when this gets done, there will not need to be a mobile.py at all, and we can use a responsive/adaptive/whatever-the-current-buzzword is single design for all screen sizes.

It sounds like a good idea to do everything from one view but my experience teaches me this is not a great approach. For a desktop you always want more information then for a Mobile (or even eInk view).
The Kindle Paperwhite happens to process -some- Javascript but other eReaders don't do any Javascript and sometimes only are able to render basic HTML with a Table.

I would still recommend a refactor and we could take a look at integrating Django's Templating for this. It's very well documented and the logic can easily be separated from the view.

Referring to the 'more code' this is what I meant :) On a Mobile view you don't need a giant Table like on an eInk device so you would probably want to serve two different views etc.

I wouldn't mind looking at creating new views and using the internal Calibre Database for proper querying into a view.

Let's keep this PR open and throw some ideas around.

PS: is it already possible to run the Calibre Content Server completely Headless? Or is there still a GUI needed for the initial installation?

[kovidgoyal]

There is nothing preventing a single view from hiding information depending on screen size.

My question about more code was why you think it is less code to create kindle.py rather than make mobile.py adapt its output based on user agent.

the server runs headless, always has.

[terwey]

There is nothing preventing a single view from hiding information depending on screen size.

As long as the View does that server side then indeed it's not much of an issue.
Still not recommended for specialised views. A Desktop view will always have more information present then a Mobile view.
And having a few hundred if statements vs. a desktop.tpl, mobile.tpl, eink.tpl is of course maintainability :)

My question about more code was why you think it is less code to create kindle.py rather than make mobile.py adapt its output based on user agent.

That was simply a duplicate, proof of concept. Also because for the Mobile View it has a different layout (div inside of a table vs 3 rows). But yes they can be merged just the lxml html builder is... ehr... not so nice ;)

[kovidgoyal]

The new server is more or less ready (currently it only has a cover grid view, but the views are modular so adding more views should be easy in the future)

calibre-debug --new-server

to see it in action

Closing this PR as it is no longer relevant.