Fat Pages FAQ

Why are you doing this?

The goal of fat pages is to simplify the installation process for small things, without requiring that many files or folders be saved in the local file system. Read-me files aren't necessary, since the explanatory text is included along with the binary information.

It will be possible to write updater scripts that visit web pages and extract the embedded information, allowing updates to happen by visiting several sites.

We believe it's a more modern system of software distribution because it leverages off the friendliness and universality of web browser software. It also takes advantage of increasing power in web development tools.

Another reason we did fat pages is that we needed a file format that worked on both Windows and the Macintosh operating systems. The web helps us bridge differences between their different file systems.

Where in the HTML document is the Fat Page information stored?

The embedded information is stored in a comment, anywhere in the page, but for best performance, it should be at the end of the page, or close to the end of the page. This allows the user to read the documentation while the embedded information is being downloaded.

What does a fat page comment look like?

Do a view source on this page. Scroll to the bottom. This page includes a one-line Hello World object.

What does the first line of the comment contain?

The first line of the comment contains the text #fatPage followed by a \n.

The second line says #version 1 followed by a \n.

This establishes the pattern. Every line begins with a #, followed by a name, followed by a string followed by a \n.

What are these things called?

They're called Attributes.

What are the minimum attributes for valid Fat Page data?

To be a fat page, it must contain three attributes: #adrPageData, #pageData, #dataType.

The comment may contain more attributes, and in fact, the ones automatically generated by Frontier do. We're looking forward and hoping to build on the other attributes in the future.

What is #adrPageData?

A string of characters, in the syntax that makes sense for the app that's going to unpack the embedded data.

For a spreadsheet, something like R4C90, would indicate that the data is to be stored in row 4, column 90.

For a hierarchic database it could be something like suites.html.ftpTable, which indicates that the object is to be stored in a cell named ftpTable in the html table in the suites table.

What is #dataType?

A string of characters, it tells the processor on the client how to treat the data.

We use MIME types here. In the Frontier implementation, the type is of the form application/x-frontier-zzzz. The last four characters identify the type of the object in Frontier's database.

Following the spreadsheet example, a type of formula, expressed as application/x-mySheet-formula, for example, would tell the spreadsheet to calculate the expression. If the type is text, the string is stored in the spreadsheet but not calculated.

These are just examples. We stick to the MIME type format, and rely on new router software on the clients to get it to the right processor with all the information they need.

What is #pageData?

A string of Base 64-encoded characters. After decoding, the format of the data is entirely up to the application that's going to be receiving it.

What is Base 64-encoding?

It's a format developed for the MIME encoding that Internet email uses. We used an existing format instead of inventing a new one. We also released the C source code for our implementation Base 64 encoding.

What about security?

To conform to this spec, no code can be executed on the client machine without the user confirming in an affirmative clear way, like clicking OK on a confirmation dialog, that it's OK for the code to run on the local system.

In the spreadsheet example, this means that if a formula is stored in a local spreadsheet, the formula must not be evaluated without user confirmation.

Further, the user must be offered an opportunity to store the data at a different location. The #adrPageData attribute, therefore, is just a suggestion.

If the location the user specifies already contains data that would be overwritten, that must be confirmed too.

Which web browsers are compatible?

Any web browser that can save a web page to a local disk is compatible.

This includes all leading web browsers.

How can authoring tools support Fat Pages?

If web authoring tools want to support Fat Pages, we will attempt to work out platform-specific protocols that allow it to query an external program while building a page to have the Fat Page comment inserted.

Why not use META tags?

META tags have to be in the HEAD section of the page. This means that before the user sees any text, they'd have to wait for the embedded information to be downloaded.

What if the embedded information is huge?

It shouldn't be. Web designers should use good judgement and understand the bandwidth constraints of their users. I don't think it's a problem to embed something that's the size of a reasonable GIF you might see on a popular web site such as CNN or Microsoft or HotWired, so under 100K probably isn't a problem in most situations.

Why not use Base64 encoding?

We changed our minds, and decided to go ahead and use it.

Does the Fat Pages logo make you think of Krusty the clown?

Hmmmm.

Dave Winer
UserLand Software
April 1997
Revised: February 1998