Comments on Fat Pages
Good fatpage, bad fatpage
I've been working a little bit more on the suites.mime project, and in doing work with encoding multi-part mime objects, I have a few comments to make about fat pages.What are fatpages?
For those of you who aren't familiar with fatpages, they are Frontier's cross-platfor m file format.
Fat pages are basically data stuffed into an HTML comment so that the Frontier data can 'ride' at the end of an HTML page.
It's a very clever format in that it takes advantage of existing standards.
For more info on fatpages, see http://www.scripting.com/fatpages/
Fatpages for the web
Fatpages were designed with the web in mind. They are easy to create, and at filsa.net, it's the distribution method of choice.
However, when sending a file via email, they are not so good. The design isn't robust enough for fragile email interfaces. Fat pages rely on carriage returns for separating data fields--however, mail servers sometimes wrap text and add carriage returns. Particularly problematic is the #pagedata field--it is usally longer than 76 characters, which is the longest legal length of a line in an smtp message.
John Delacour has a suite called mimi that addresses sending Frontier objects by mail. Although it is an excellent and clever piece of programming, I myself long for something that is already part of Frontier to handle sending objects by mail.
Frontier Objects By Mail
MIME objects are only supposed to be encoded once--that is, the client machine should not have to continually decode one coding scheme after another to get to its data.
Fatpages already encode Frontier data in base64, one of the standard formats for email. However, it allows the #pagedata to be longer than 76 characters, which, as mentioned above, will break as it goes across the internet's varied mail servers.
suites.mime and fatpages
The data table at webserver.data.prefs.ext2MIME suggests that fatpages should treated as text/html. However, in html, carriage returns and whitespace are not important--inserting extract carriage returns inside of a html page doesn't affect how the browser displays it. In fatpages, this is vital.
In order to ensure that fatpages survive mail servers, the fatpage should be base64 encoded--but this is redundant because the frontier object data has already been bas64 encoded by the fatpage exporter. Besides it being a burden on the client machine, this also causes the size of the object to bloat, and wastes alot of bandwidth.
Although people today have faster system and more bandwidth, many people still work on modem dialup connections. It's inconsiderate to ignore bandwidth issues.
I will say that I have sent raw fatpages via email many times; I have yet to be bitten by an older mail server that chopped up my data (although popular servers like Hotmail and mailCity will butcher fatpages). At some point this will affect someone negatively--which is a shame, since the problem is easily engineered around.
FatPages version 2
I propose that a new version of fatpages be supported. The new format would be mail friendly-- instead of directive style #fieldname fieldvalue lines, SMTP-like headers would be used.
Fatpage-version: 1,docs="http://www.scripting.com/fatpages/faq.html"
Fatpage-adrPageData: workspace.example
Fatpage-objecttype: application/frontier-tabl;runnable=false
SDFwefefsfpagedatagoesherevksjfdkfjsdfkjfklfjsdfsd . . .
The body of the object (#pagedata) would be separated from the headers with 2 CRLF sequences, just like the body of a mail message. The pagedata would be base64 encoded, in lines 76 characters long.
By enclosing this in HTML comments, it could very easily be added to web pages as well.
Another version
Even easier, just rewrite the parser so that when it hits the #pagedata field, it looks for the end of the data (may need to add a marker) and then take all the carriage returns out of the pagedata (which has been properly base64'd for email).
#fatpage
#docs http://www.scripting.com/fatpages/faq.html
#version 2.1
#adrPagedata workspace.example
#pagedata
pagedatagoeshere.......
suites.mime prototypes
I still haven't decided what direction to take with fatpages and suites.mime. The easiest immediate 'solution' is to ignore it entirely; RFCs be damned.
However, at some point, I hope to provide a prototype of the new fatPages format.
Why bother with this discussion?
Some this detail is admittedly anal. I think after reading all the RFCs about MIME, one gets very picky about implementation details. You have to, or things won't work.
I'm very interested in making fatpages work, for everyone. It'd certainly very possible. fatpages are an excellent format, but they were designed with the web in mind.
By opening up our thinking, and the fatpage design, we can make something that works just fine in email as well.
That'd be another win.
| Site Outline | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I&I Home
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Back to I&I Home >> |
|
Back to the top |
|
This is Phil's Frontier Scripting Site. San Francisco, CA
Copyright © 1996-98, Phil Suh. All Rights Reserved.
http://www.filsa.net/frontier/ii/1998/08/commentsOnFatpages.html
This page last built on 6/28/99; 11:08:07 PM