[Cosmo-dev] Bug 10304 and base64 encoding
travis at osafoundation.org
Mon Sep 10 08:55:56 PDT 2007
A good amount of time was spent at the end of last week tracking down
It turns out this bug is due to one of the server layers using an
unexpected default encoding when Cosmo is run on a Mac. As a result,
this problem does not manifest itself on server instances hosted on a
Linux machine. In particular, we're pretty sure this has never shown
up on the Hub instance. As a result, Brian recommends in the bug that
we punt until 0.8 or later, and I agree.
At the moment we still have a number of changes from this bug
checked in to the 0.7.2 branch. Probably the biggest change in terms
of impacting user experience is the new base64 encoding of Atom entry
During the bug tracking process we checked in some code to base64
encode the body of the <content> elements in the Atom feeds we get in
the web ui. This was an attempt to find out whether base64 encoding
would avoid the problem we seemed to be having with some of the more
exotic unicode characters. Interestingly, it did, but this did not
solve our problem completely, as the unicode characters were showing
up in other places in the feed and the same bug (IE breakage and feed
validation failure) was manifesting.
The results of this change include roughly a 20% increase in the size
of feeds (8k->10k for the default "Home" collection and 138k -> 162k
for the office calendar) and a considerable amount of extra client
side processing (every character in the feed is run through the
really hasn't been tested thoroughly.
The one upside of this is that we're technically compliant with the
Atom specification, though we could achieve this by changing the
"type" attribute of our entries to "text/eim-json+xml" as well.
As a result, I'd like to back out the base64 encoding changes from
the 0.7.2 branch. Any objections? If I don't hear anything I'm going
to do this this afternoon (Monday the 10th).
More information about the cosmo-dev