[Cosmo-dev] Bug 10304 and base64 encoding
bcm at osafoundation.org
Mon Sep 10 10:59:14 PDT 2007
On 9/10/07, Travis Vachon <travis at osafoundation.org> wrote:
> 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.
i presume you mean every character in the entry content is decoded,
not every character in the feed.
> 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.
using a "text/" mime type to describe data structures rather than text
meant to be read by an "end user" is deprecated in modern standards.
the argument was made in irc on friday that "we have the regular
(basic) feed; that can be the standards-compliant one, and this one
(the full feed) can be uncompliant". sorry, that argument doesn't hold
* the basic feed is meant to be consumed by feed readers. the content
of its entries are html. the content is abbreviated and express a
minimal amount of information about an item (event dates, location,
title and summary). it is not suitable for full client display and
manipulation of all information about an item.
* the full feed (whether delivering json or xml) is not meant to
convey directly human readable information. its purpose is to transfer
the complete state of an item between two programs. to do this, we use
data structures that are marshalled into a form that happens to
conveniently be sort-of-readable-if-you-squint-hard-enough by
if this was a private protocol not intended for use by any other
application, i wouldn't care so much if we were not spec-compliant,
but that's not the case. people coming from outside the project who
want to write cosmo feed clients with off-the-shelf atom libraries
will be mightily confused, or even completely blocked, if eim-json
uses an "application/" mime type without base64 encoding.
> 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).
-1 as the proposal stands. -0 to changing the mime type to a primary
type of "text"; before we take this step, i would like to see proof
that the web ui with base64 encoding is not "fast enough".
More information about the cosmo-dev