On Thu, Mar 27, 2008 at 4:05 PM, Paul Lindner <[EMAIL PROTECTED]> wrote: > * Is it necessary to surface GadgetExceptions in many places?
Reasonable question. I need some mechanism to break out of the content fetching chain with an error in order to support OAuth, and decided that now would be a good time to get the interface change done. The old interface of RemoteContentFetcher overloaded the response so it was unclear whether a 'server error' RemoteContent actually came from a remote server or not. I don't like the idea of mixing together errors from remote servers and errors in the gadget server. Combining data and control channels leads to trouble. One option would be to annotate the RemoteContent object with additional information about the processing chain. That seems reasonable, except that people might ignore important annotations. An exception must be handled. > * Is there any particular reason BlobCrypter is calling > URLDecoder.decode()? Maybe we should rename it UrlEncodedBlobCrypter :) This is a fix for a separate bug I noticed. The BlobCrypter encodes name/value pairs in something resembling x-www-form-urlencoded form, so that you can encode things like a key of 'foo' mapping to a value of 'blah=bar' unambiguously. The original code neglected to reverse this process on the other end, leading to corruption of values that have embedded spaces, newlines, or other characters that are encoded by URLEncoder. The wire format used by BlobCrypter isn't terribly important, but once things are more widely deployed we'll have to be cautious about changing it to avoid backwards compatibility issues. We could use JSON, we could use XML, we could use anything. I went with x-www-form-urlencoded because writing parsing code is easy in most languages, so in theory a PHP container could easily generate encrypted blobs that a java gadget server could handle, and vice versa.
