Tickets :: Comment on [#2565] Firefox 3 bookmarks extension

* Your Email Address
* Spam protection	Enter the letters below: .__ .__..__ .__ . . \| \\| \|[__)[__)\ / \|__/\|__\|\| \\| \ \/
Comment	> Several thoughts: > > > >> I also switched to JSON. I basically just made an interface to the > >> RPC calls I already wrote. The change wasn't quite as "drop-in" > >> simple as I would have liked, but I've gotten rid of another layer of > >> translation that used to be there for XML-RPC. I'm kind of hoping > >> :-) that the MacOS bug was caused by using XML-RPC, which was > >> implemented by a built-in Firefox XPCOM component. Perhaps it was a > >> little different than Windows on the COM side... > > > > If you still rely on the external API methods defined for Trean > instead of calling the Trean API directly in json.php, would it make > more sense to add a generic JSON backend to Horde's RPC library? > > > >> I'm still not sure whether JSON is the best way to go, but I'm happy > >> for the moment because it cleaned up the code and may be more > >> efficient. At the moment slightly more bytes go over the wires > >> because XML-RPC was gzip-compressed, but I don't know how to do that > >> for my JSON code. Anyone know how to do it? > > > > It's only an issue for reading the bookmarks, right? A > Horde::compressOutput() in json.php should probably do that trick > then. > > > >> I'd also appreciate some assurance that I got JSON security right. I > >> understand a comment or "while(1);" at the beginning is enough to > >> stop people from being able to XSS your data. > > > > Should be. > > > > Regarding the AJAX and JSON stuff inside the XPI, I suggest that you > use prototype that we use anywhere else in Horde. The most recent > version has support for a CSRF protection built in. > > Heck, we could even build the XPI on the fly including the source > files directly. Much easier than rebuilding the XPI anytime you > change something. I plan to do this for IMP since ages.
Attachment
Watch this ticket

Saved Queries