[Cosmo-dev] Bug 10304 and base64 encoding

Travis Vachon travis at osafoundation.org
Mon Sep 10 11:12:17 PDT 2007

Hi Brian

Thanks for the reply, see below:

On Sep 10, 2007, at 10:59 AM, Brian Moseley wrote:

> 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
>> JavaScript UTF-8 and Base64 decoding code). In addition, this code
>> really hasn't been tested thoroughly.
> i presume you mean every character in the entry content is decoded,
> not every character in the feed.

Yep, thanks for the catch :)

>> 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
> water:

I agree with you. However, I don't think a change this large, with no  
justification other than "it brings us into compliance" belongs in a  
maintenance release.
>> 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".

Unfortunately, I'm -1 on leaving the code as-is in 0.7.2. I'm +0 on  
your proposal, but am still confused why any of these changes belong  
in this particular release. To be clear, I would be perfectly content  
moving all of these changes (base64 encoding included!) into trunk.


> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev

More information about the cosmo-dev mailing list