Thanks for your note, Andrew. Comments below: On Tue, Apr 03, 2018 at 12:01:43PM -0700, Andrew Sly wrote:
Hi Greg. Thanks for the message.
My understanding is that you want to change some of the behind-the-scenes procedures for how information about PG texts are presented to users, to use more static files, and less back-end processing.
Based on previous experience, I would like to be aware of how this could affect those of us editing the catalog.
The intention is to regenerate the static HTML pages from the catalog, whenever something changes. This is the current practice for automatically generated content (epub, mobi, etc.).
Are you talking about still having a database, but generating static files from it, that are presented to users? Or are you talking about doing away with a central database altogether?
No, we'll keep the database. Maybe there will be some changes, but it will remain the canonical information source.
Experience has shown that you do not want to automatically update catalog information when a book is updated or changed. There is a good chance you can overwrite improvements from catalog editors that way.
Yes, this happens sometimes, still. For the most part, though, Marcello implemented some mechanisms to try to make sure that when other things change (i.e., updates to an eBook's files) it does not over-write anything in the database. That is definitely the same approach we will take. If eventually we end up with changes coming from elsewhere, we need to make sure they get into the database. For example, I have often wanted to crowdsource the addition of Wikipedia entries for authors and books. If that happens elsewhere (say, via a github-type process), I would want it to go back into the database, before being pushed out to the static pages. BTW, we have representation of the structured info from the database in every cache/epub directory (a little XML/RDF file). So, the database entries are already part of an eBook's files, but it's *from* the database, not input *to* the database. - Greg
On Mon, 26 Mar 2018, Greg Newby wrote:
I am wondering whether you have ideas about how to present a more effective landing page for our eBooks.
The situation is that I am trying to make the collection more self-contained, and remove some of the back-end processing we use to present information about the books.
Take a look at any current eBook landing page, such as https://www.gutenberg.org/ebooks/56843
This is plain HTML (with Javascript and CSS), but it does not come from a static file. Basically, what I'd like to do is recreate a similar page, but as a static file, without relying on a back-end database, and without using Javascript. I.e., plain HTML with CSS.
The actual files are in a location like this: https://www.gutenberg.org/files/56843/
My intention is to make a directory (folder) that has those files, plus the generated files (i.e., you can see them here: http://aleph.gutenberg.org/cache/epub/56843/) plus an index.htm or similar that presents the landing page.
Oh, and we'll give all the files nice human-friendly usernames. There is already some code for that in epubmaker.
MY INQUIRY is for ideas about the index.htm or similar that would be similar to the current landing page, but be (a) static, and (b) use no Javascript or other active content, and (c) allow variations on CSS, to have different "skins" for different viewers. General ideas:
- HTML5 - works well with mobile and desktop - works well with text browsers and screen readers - might need to have two pages: one for bibrec info ("about.htm" perhaps?) and the other to access - get CSS style information from e.g., /gutensite/ , so that it is easy for people to apply their own styles. For example, mirrors might not want the dropbox/cloud links)
I'm very interested in any mockups that you can think of. The idea will be to generate these static pages when new eBooks are added/updated.
That way, when someone visits a page like https://www.gutenberg.org/ebooks/56843 , they will be seeing the static content under ebooks/56843.
Currently, there is no such static content: it is all generated by a set of back-end Web-database applications.
Thanks, Greg