Alternative Web Content Server Layout - Page 2

bossanova808 · 10-07-2017, 08:24 PM

Well all I can say is I have about 25 folks here who don't agree. If you're in this forum, you're not the tech novice sort of user @gbm mentioned by definition I'd say

BetterRed · 10-07-2017, 10:45 PM

@bossanova808 fyi ==>> Server to-do list

Do you have a link to an application implemented in Twig - I mean the actual application not the code that implements it. I'll be frank - as a general rule I do not like web based software. In most instances I feel like I am floundering around in a drum of molasses.

BR

bossanova808 · 10-07-2017, 11:03 PM

Well twig is used with a lot of things, but one example I like is:
https://craftcms.com/

With source code for the soon to released V3 at: https://github.com/craftcms/cms

Now that's a full flight (web) content management system....but in many ways, in the content server context, that's how Calibre is acting. History has shown really need two things - a query system and a totally design independent templating system for the actual front end. Calibre probably already has most of what it needs for querying I suppose...

Twig, though, is definitely NOT an application language as such, rather a templating language (which came from the Symfony PHP framework originally, although I believe the syntax is based on Django ultimately...) - https://twig.symfony.com/

Twig is very popular in the PHP world. Not probably the right thing for this, I would thing. Jinja2 would appear to be a quite similar thing for the Python world -http://jinja.pocoo.org/docs/2.9/

kovidgoyal · 10-08-2017, 12:08 AM

The existing templating system works for the book list not the single book view. The single books view has its own set of customization settings. But I doubt you bothered to take the time to look for them. And just FYI the current interface is implemented purely using web technologies on top af a JSON API. And yet, I have noticed no horde of people with HTML skills volunteering their efforts to work on it.

You keep saying that the interface looks like it comes form the 90s as if that is some kind of insult. I find that highly amusing. Not to mention that you also complain that the interface is optimized for touch. But lets not worry about small things like consistency in our complaints shall we?

Anyway, I can tell you that you are going to get nowhere with your approach. You want to criticise something, do it constructively. At a minimum, remember that design is all about trade-offs. Acknowledge the upside of tradeoffs as well as the downside if you want to have a hope of not being dismissed out of hand. And dont make demands of other people's time unless you are willing to at least contribute some of yours beyond complaining.

bossanova808 · 10-08-2017, 12:59 AM

I'm not making any demands, I was asking why it was done the way it was, i.e. with an embedded server approach...basing it on the numerous questions on this forum where you yourself have answered the content server interface can not be replaced and that people should look to the alternatives that reach into the DB like calibre-web etc.

But if there's a JSON api that's great in theory - is there documentation for this somewhere (I can't see any with some googling)? It might be no-one is offering to build something on it because it's not clear it's even there.... Is the only documentation looking through this - https://github.com/kovidgoyal/calibr...re/srv/ajax.py ?

..because for a typical web dev, that's not really going to work for them as documentation.

Perhaps you or someone could take me through very quickly what is there & how it currently works, where to look etc. For the content server parts that are outside of the python area, that is.

(I'm afraid, though, it is actually possible & consistent for it to both look visually unappealing and dated (as I believe it does), and in functional terms be touch optimised to the extent that it's unfriendly to use on the desktop (as I think it is)). Watching users use it has shown me it's now not doing the job it wants to do very well (assuming that is to present a library and allow for the discovery of books in that library)...whereas previously it was quite decent at it.

Even quite computer savvy people seem to find the new implementation on desktop clunky, and I personally agree with them. I apologise for the web criticism but I wouldn't be typing all this if I didn't care - and generally think Calibre is great and very useful. But I do think for the web interface side of things, the recent changes are quite a step back for the browsing a library. (I don't personally read in browsers or know anyone who does, so this is just about the library browsing side of things).

And of course, I may be wrong - certainly have been before. Do folks genuinely think the new interface is, for library purposes, better than the old one?

kovidgoyal · 10-08-2017, 01:17 AM

The entire (new) content server interface is in a single HTML file index-generated.html (look in the resources/content-server directory of the calibre installation). The javascript in that file contacts various JSON end-points on the server. So if you want to make a new interface for the server, all you need to do is replace index-generated.html with whatever floats your boat.

Of course, if you want your interface to be available to other calibre users, then it would require a few lines of python to add the appropriate end point to serve up that html. It is on my TODO list to pluginize this, so you can have content server plugin that are self contained with all their assets, but loaded by the content server to make new endpoints available.

I agree that the JSON API needs documentation, but at least as far as I am concerned, that will not come until I am done with the plugin system I spoke of earlier. Contributions to the documentation are welcome.

To get a list of endpoints the server currently supports simply grep for @endpoint in the calibre/srv directory. Note that this JSON API is used not just by the HTML interface but also by calibredb when connecting to the server as a backend, and other third party apps that present custom interfaces to the server.

Finally, let me just say that the new interface is optimized for use on a mobile device, where lots of people like the fact that they can read books in a browser without needing yet another privacy invading third party app.

It's certainly possible that in optimizing for that, there are regressions in usage for your particualr use case, which seems to be distributing books to other people via desktop browsers. So *specific*, *actionable* suggestions on improving the interface for that use case are welcome. I am also open to adding a whole different interface for that use case, much as the /mobile interface exists already for people using outdated browsers. Indeed you might find the /mobile interface better suited to your needs.

bossanova808 · 10-08-2017, 01:49 AM

Ok, many thanks - I shall have a look at what's there for sure.

BigRedBrent · 10-13-2017, 03:14 PM

I found this php script that works well with the xampp apache server:
COPS (Calibre OPDS PHP Server)
https://github.com/seblucas/cops/releases

bossanova808 · 10-13-2017, 06:31 PM

@BigRedBrent

Have you also tried https://github.com/janeczku/calibre-web - it's quite nice.

BigRedBrent · 10-20-2017, 12:52 AM

Quote:

Originally Posted by bossanova808

@BigRedBrent

Have you also tried https://github.com/janeczku/calibre-web - it's quite nice.

No, but Calibre OPDS PHP Server seems to be very easy to setup and configure. At least I had no trouble setting it up. The one you listed, seems a lot more complicated to set up, from looking at the readme file for it.

sjfan · 10-20-2017, 01:47 PM

Quote:

Originally Posted by BigRedBrent

No, but Calibre OPDS PHP Server seems to be very easy to setup and configure. At least I had no trouble setting it up. The one you listed, seems a lot more complicated to set up, from looking at the readme file for it.

calibre-web is actually somewhat easier to setup unless you already have a web server configured, in which case it's a wash. After downloading, you just run the pip install command (once) and then the startup command. It has its own integrated web server so you don't need to set up and configure Apache/IIS/nginx/whatever.

Calibre OPDS requires you to have a web server with PHP support configured first, and still needs similar install and run commands after downloading.

(Both require you to have the appropriate language runtime--Python or PHP--installed first, of course).

bossanova808 · 10-20-2017, 07:09 PM

Yes I find it (calibre-web) reasonably easy to set up, and I even do have an existing web server...putting it behind a virtual host worked ok too. And it's a much easier & nicer looking interface than the built in one, for my tastes anyway. It's just running another server is a pain, really...just one more thing to support/maintain. I ran out of time but in testing it seemed overall like the best option, I hope to get back to it soon.

10-13-2017, 03:14 PM	#23
BigRedBrent Junior Member Posts: 3 Karma: 10 Join Date: Oct 2017 Device: Kindle Paperwhite	I found this php script that works well with the xampp apache server: COPS (Calibre OPDS PHP Server) https://github.com/seblucas/cops/releases Last edited by BigRedBrent; 10-13-2017 at 03:45 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Content Server - Web	jojovee	Development	2	08-16-2017 02:56 PM
Calibre Content Server from web app	assur191	Development	1	01-30-2015 12:41 PM
Web Content Server Metadata Control	r_sauve	Library Management	4	05-24-2013 06:30 AM
Can I make minor adjustments to the layout of the Content Server?	MyNameIsMrBurns	Library Management	1	01-06-2012 09:11 PM
Web Content Server	mezme	Calibre	7	01-08-2010 09:59 PM

10-07-2017, 08:24 PM	#16
bossanova808 Enthusiast Posts: 35 Karma: 10 Join Date: Apr 2011 Device: Many	Well all I can say is I have about 25 folks here who don't agree. If you're in this forum, you're not the tech novice sort of user @gbm mentioned by definition I'd say

10-07-2017, 10:45 PM	#17
BetterRed null operator (he/him) Posts: 21,742 Karma: 30237526 Join Date: Mar 2012 Location: Sydney Australia Device: none	@bossanova808 fyi ==>> Server to-do list Do you have a link to an application implemented in Twig - I mean the actual application not the code that implements it. I'll be frank - as a general rule I do not like web based software. In most instances I feel like I am floundering around in a drum of molasses. BR

10-07-2017, 11:03 PM	#18
bossanova808 Enthusiast Posts: 35 Karma: 10 Join Date: Apr 2011 Device: Many	Well twig is used with a lot of things, but one example I like is: https://craftcms.com/ With source code for the soon to released V3 at: https://github.com/craftcms/cms Now that's a full flight (web) content management system....but in many ways, in the content server context, that's how Calibre is acting. History has shown really need two things - a query system and a totally design independent templating system for the actual front end. Calibre probably already has most of what it needs for querying I suppose... Twig, though, is definitely NOT an application language as such, rather a templating language (which came from the Symfony PHP framework originally, although I believe the syntax is based on Django ultimately...) - https://twig.symfony.com/ Twig is very popular in the PHP world. Not probably the right thing for this, I would thing. Jinja2 would appear to be a quite similar thing for the Python world -http://jinja.pocoo.org/docs/2.9/

10-08-2017, 12:08 AM	#19
kovidgoyal creator of calibre Posts: 45,377 Karma: 27230406 Join Date: Oct 2006 Location: Mumbai, India Device: Various	The existing templating system works for the book list not the single book view. The single books view has its own set of customization settings. But I doubt you bothered to take the time to look for them. And just FYI the current interface is implemented purely using web technologies on top af a JSON API. And yet, I have noticed no horde of people with HTML skills volunteering their efforts to work on it. You keep saying that the interface looks like it comes form the 90s as if that is some kind of insult. I find that highly amusing. Not to mention that you also complain that the interface is optimized for touch. But lets not worry about small things like consistency in our complaints shall we? Anyway, I can tell you that you are going to get nowhere with your approach. You want to criticise something, do it constructively. At a minimum, remember that design is all about trade-offs. Acknowledge the upside of tradeoffs as well as the downside if you want to have a hope of not being dismissed out of hand. And dont make demands of other people's time unless you are willing to at least contribute some of yours beyond complaining.

10-08-2017, 12:59 AM	#20
bossanova808 Enthusiast Posts: 35 Karma: 10 Join Date: Apr 2011 Device: Many	I'm not making any demands, I was asking why it was done the way it was, i.e. with an embedded server approach...basing it on the numerous questions on this forum where you yourself have answered the content server interface can not be replaced and that people should look to the alternatives that reach into the DB like calibre-web etc. But if there's a JSON api that's great in theory - is there documentation for this somewhere (I can't see any with some googling)? It might be no-one is offering to build something on it because it's not clear it's even there.... Is the only documentation looking through this - https://github.com/kovidgoyal/calibr...re/srv/ajax.py ? ..because for a typical web dev, that's not really going to work for them as documentation. Perhaps you or someone could take me through very quickly what is there & how it currently works, where to look etc. For the content server parts that are outside of the python area, that is. (I'm afraid, though, it is actually possible & consistent for it to both look visually unappealing and dated (as I believe it does), and in functional terms be touch optimised to the extent that it's unfriendly to use on the desktop (as I think it is)). Watching users use it has shown me it's now not doing the job it wants to do very well (assuming that is to present a library and allow for the discovery of books in that library)...whereas previously it was quite decent at it. Even quite computer savvy people seem to find the new implementation on desktop clunky, and I personally agree with them. I apologise for the web criticism but I wouldn't be typing all this if I didn't care - and generally think Calibre is great and very useful. But I do think for the web interface side of things, the recent changes are quite a step back for the browsing a library. (I don't personally read in browsers or know anyone who does, so this is just about the library browsing side of things). And of course, I may be wrong - certainly have been before. Do folks genuinely think the new interface is, for library purposes, better than the old one?

10-08-2017, 01:17 AM	#21
kovidgoyal creator of calibre Posts: 45,377 Karma: 27230406 Join Date: Oct 2006 Location: Mumbai, India Device: Various	The entire (new) content server interface is in a single HTML file index-generated.html (look in the resources/content-server directory of the calibre installation). The javascript in that file contacts various JSON end-points on the server. So if you want to make a new interface for the server, all you need to do is replace index-generated.html with whatever floats your boat. Of course, if you want your interface to be available to other calibre users, then it would require a few lines of python to add the appropriate end point to serve up that html. It is on my TODO list to pluginize this, so you can have content server plugin that are self contained with all their assets, but loaded by the content server to make new endpoints available. I agree that the JSON API needs documentation, but at least as far as I am concerned, that will not come until I am done with the plugin system I spoke of earlier. Contributions to the documentation are welcome. To get a list of endpoints the server currently supports simply grep for @endpoint in the calibre/srv directory. Note that this JSON API is used not just by the HTML interface but also by calibredb when connecting to the server as a backend, and other third party apps that present custom interfaces to the server. Finally, let me just say that the new interface is optimized for use on a mobile device, where lots of people like the fact that they can read books in a browser without needing yet another privacy invading third party app. It's certainly possible that in optimizing for that, there are regressions in usage for your particualr use case, which seems to be distributing books to other people via desktop browsers. So specific, actionable suggestions on improving the interface for that use case are welcome. I am also open to adding a whole different interface for that use case, much as the /mobile interface exists already for people using outdated browsers. Indeed you might find the /mobile interface better suited to your needs.

10-08-2017, 01:49 AM	#22
bossanova808 Enthusiast Posts: 35 Karma: 10 Join Date: Apr 2011 Device: Many	Ok, many thanks - I shall have a look at what's there for sure.

10-13-2017, 06:31 PM	#24
bossanova808 Enthusiast Posts: 35 Karma: 10 Join Date: Apr 2011 Device: Many	@BigRedBrent Have you also tried https://github.com/janeczku/calibre-web - it's quite nice.

10-20-2017, 07:09 PM	#27
bossanova808 Enthusiast Posts: 35 Karma: 10 Join Date: Apr 2011 Device: Many	Yes I find it (calibre-web) reasonably easy to set up, and I even do have an existing web server...putting it behind a virtual host worked ok too. And it's a much easier & nicer looking interface than the built in one, for my tastes anyway. It's just running another server is a pain, really...just one more thing to support/maintain. I ran out of time but in testing it seemed overall like the best option, I hope to get back to it soon.

Advert

Advert