[Cosmo-dev] Bug 10304 and base64 encoding

[Travis Vachon]

So given the discussion I think we've come to a compromise proposal:

1) Revert base64 changes in 0.7.2 branch
2) Change default eim-json media type to "text/eim-json" in 0.7.2 branch

According to the conversation so far Brian is -0 on this. I'm going  
to change my vote to +1 after considering the protocol compliance  
argument.

The base64 changes have been committed to trunk, so my current plan  
is to _not_ commit the changes proposed here back. This gives us time  
before 0.8 to get some benchmarks and have a bit more discussion on  
whether we should go with base64 encoding or a "text/" type attribute  
for content elements.

Comments and +/-0/1 welcome, I'm going to push back the timeframe for  
taking action on this to the end of the day.

Thanks!

-Travis

On Sep 10, 2007, at 11:53 AM, Brian Moseley wrote:

> On 9/10/07, Bobby Rullo <br at osafoundation.org> wrote:
>
>> Because we invented EIM+JSON.
>
> and it's documented on our wiki and available for anybody to write a
> client to use.
>
>> Ok. but what about ease of debugging, and size of data?
>
> i grant that you can't read the data over the wire, but that's true of
> any binary protocol or encoded text packet, and the world's moved
> along fine using plenty of those. in this specific case, you can use
> firebug to look at the decoded data, right?
>
> size of data only matters when it's a problem. encoding the data has
> yet to be proven to be a real problem for us with production-like
> data. if/when it has, we can consider alternatives. remember that in
> production we're gzipping the entire feed, so the reality of the extra
> 20% is less.
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev