Your documents stay yours

Where a request lives while it is drawn

A request arrives as a form. One part of it carries the description of the document as text; every other part is a file the description may draw on, such as a sheet of headed paper, a picture, a colour profile or the figures of an invoice. All of it is read into memory, and the description is turned into the shapes the drawing works from as soon as it lands.

The drawing itself runs on a worker of its own, so a long document leaves the rest of the service answering. What comes out is a block of bytes: that block is the answer, and it is handed to the network as it stands. The memory holding the request, the files that came with it and the finished pages is released as soon as the answer is on its way.

The service also runs with a temporary area private to itself, which the machine empties when the service stops.

What reaches the disk, and it is a short list

Two places in the whole of the service write a file, and both are there on purpose.

• A queue for the bill. One short line per document, holding four things: the name of the account, the moment, the page count, and an identifier standing for that one drawing. A line leaves the queue as soon as this site has taken it, so in ordinary running the file is empty.
• A folder of lettering per account. An account allowed to draw with lettering of its own has the fonts its drawings really used kept for it, so that the next request need only name them.

What the log holds

The drawing writes one kind of line, and it writes it when it has a remark to make: a font, a picture or a colour the description supplied and the page then left out. The line carries the name of the account and the remark. The pages come back either way, since that is a remark and not a refusal.

A remark names the thing it is about by the label the library gave it while drawing, which is a serial one. The words you chose stay inside your own document.

The remaining lines belong to starting up and to reporting the bill: the address the service listens on, and what this site answered when a report reached it.

How the service knows who is calling

Your key is held by this website. The front standing before the drawing machine matches the key a request carries against a list this site writes, and passes on a short name for your account. That short name is the whole of what the drawing machine is told about the caller, and the whole of what it goes on.

Withdrawing a key is therefore a matter of rewriting that list, and it takes effect at once.

What this website keeps, which is a different question

The machine serving these pages keeps a visit log, as every web server does. For each request it holds the address the browser came from, the moment, the page asked for, the answer given and its size, the page that sent the visitor, and the name the browser gives itself. It is kept a fortnight, and then it rolls off.

It is read for one thing: how the site is found. Which search engine passed, at what cadence, which pages it took, and which published pages nobody has ever landed on. The log holds pages, and pages alone: the site's own pictures and stylesheets are served straight.

On your own machines

The counting is switched on by naming an address to send it to. A drawing machine keeps its counting to itself until it is given one, which is how a copy running on your premises behaves as it comes.

The request, step by step

• A document is asked for with one call, posted as a multipart form. The part named for the description carries it as text; every other part is held under its own name and is a file the description may draw on.
• Each part is read whole into memory. The description is parsed into the structures the drawing works from, and the raw text is released the moment that parsing is done.
• The parsed request and the files that came with it are handed to a blocking worker, and both are released when it returns.
• How large a request may be is a setting of the service, which allows 512 megabytes as it comes.

The two files the service writes

Two places in the whole of the service create a file. Here is each of them, and what it holds.

• The queue for the bill: one line of structured text per document, carrying four fields and no others — the client name, an identifier drawn fresh for that drawing, the moment to the microsecond, and the page count. A line is written before the report goes out and removed once this site has acknowledged it, so the file sits empty between reports. The queue exists at all only when the service was started with an address to report to.
• The store of a client's lettering: when an account carries the right to draw with lettering of its own, the fonts a successful drawing really used are written into a folder named for that account, and read back into memory the next time the service starts. The store grows by exactly that: the fonts a drawing that came out really set text with. Each file is written under a temporary name in that same folder and renamed into place, and the name is held to letters, digits, a dot, a dash and an underscore, 64 of them at most.

The one line the drawing writes

On the drawing path there is a single log statement. It fires when the library has a remark about the finished document, and it holds two things: the client name as the front supplied it, and the remark itself.

A remark reads that some resource was supplied and never drawn with, and it names that resource by the label the library assigned it while writing the file — a serial one for a font, another for a picture, another for a colour space. The words that can appear there are the library's own labels, and those alone.

The remaining statements sit outside the drawing: the address the service binds at startup, a warning about the machine's store of certificates, and, in the reporting of the bill, what this site answered to a report. The service writes to its standard output, at the level the machine's own journal collects.

What travels back in an answer

A drawing that succeeded answers with the PDF itself, and two headers saying how long reading the description took and how long the drawing took.

A request the service could not use answers with a sentence naming what stopped it. That sentence is written for you and travels in the answer to your own call. Where what stopped it is a square code, the sentence quotes the text you asked that code to carry, because that is what tells you which of them it was.

An error becomes an answer to your call, and that answer is the whole of its life.

What the finished PDF carries

• A title, an author, a subject and the name of the producing program are written when your request states them, and the block that carries them is built from what your request states.
• A creation date appears when your request gives one: every date inside a finished document came from the request that asked for it. Where a request asks in so many words for the day to be drawn on the page, the machine's own clock and time zone answer, and the date drawn is what those show.
• Every PDF carries an identifier. This one is a fingerprint of the bytes just written, so the same description yields the same file twice over, which is what lets you compare two runs and see for yourself that the two are the same to the byte.
• Under a licence key the pages come out clean. A copy running without one marks every page it draws and says so on the page, and that mark is the whole of the difference between the two.

Your key, and the name that stands for it

The key lives on this site, and this site is the only place holding it. The front turns it into a client name and forwards that name in a header of its own, so the front is the only thing that ever sees the key; the drawing machine goes on the name.

On this site, one row is kept per document drawn: the account, the client name the drawing was made under, the identifier of that drawing, the moment, and the page count. A month of those rows is what an invoice is added up from.

The website's visit log, in full

The web server standing before these pages writes one line per request. It holds the address the request came from, the name of the account when the request carried one, the moment, the request line itself, the code of the answer and the number of bytes it sent, the page that referred the visitor, the name the browser gives itself, and the two names of the host asked for.

Lines are rotated daily and fourteen days are kept, compressed, which puts the oldest visit a fortnight back. Its lines are the pages a visitor asked for; the site's own static files and the requests turned away as probes are served straight.

A report in the site's own code reads those lines to answer five questions about how the site is found: which search engines passed and at what cadence, whether an agent calling itself a search engine really is one, which published pages no engine has taken, which visitors arrived from a search and where they landed, and which requests looked for something this site has never had.

An address that asked, several times over, for pages this site has never had is written into a short list the web server reads, and its later requests are turned away at the door. That list is short, it holds addresses and nothing else, and it is edited by hand.

Running the service yourself

Started without an address to report to, the service keeps its counting to itself, and the two files reduce to the store of lettering alone. Started without a folder of lettering for a client, that client's lettering lives for the drawing that used it and for as long as that drawing takes.