On Wed, Feb 20, 2008 at 6:37 PM, Paul Lindner <[EMAIL PROTECTED]> wrote:
> I don't see ifpc module support listed at > http://code.google.com/apis/gadgets/docs/reference/ > > I do see rpc listed there. Is this for type URL gadgets? I don't > know of any spec that required a <Require feature="ifpc"/> anywhere... rpc is an attempt to address the shortcomings of IFPC; ultimately we want to phase out IFPC entirely, but if we change all of shindig from using ifpc to using rpc today, we will wind up breaking anyone that was in the process of migrating from using gmodules.com to shindig. ifpc *will* be removed, but it needs to stick around for a bit longer. gadgets.ifpc was actually implemented before the gadgets.rpc spec was created, in an attempt to emulate what current gmodules.com is doing. While gadgets.rpc is definitely the "right" architectural model to go with at this point in time (and Zhen's work is excellent), we do have to worry about compatibility. In short, it's the same reason why we have the legacy.js file -- it's a big hack to make adopting opensocial (and in particular, shindig's implementation) easier. In any case what's it going to be? Lots of feature requests have been > shot down because they were not listed in the spec. We have to look at it on a case by case basis. If something is very popular today (a significant percentage of the existing gadgets use it), we have to provide these sorts of unfortunate hacks to deal with it (see: ifpc, legacy.js, various legacy mappings, the entire "gadgets.Prefs" library). At the same time, we don't want to get distracted with trying to support every minor feature that gmodules.com supports today just to maintain perfect parity (especially not when the feature inherently depends on some google-proprietary service). We really don't want to encourage even more gadgets to be developed using these non-standard libraries if we can avoid it. If this is > important for gmodules.com, but is not part of the gadgets spec then > perhaps it's something that can be maintained separately. It isn't important for gmodules.com itself (igoogle continues to use ifpc today, and when igoogle starts using shindig they will be using gadgets.rpcbecause it's a lot more efficient) -- it's important for containers that render on gmodules.com today and are relying on ifpc working that are trying to migrate to using shindig as their rendering mechanism. Before google decided to turn the gadgets platform into an open standard, many sites were using gmodules.com to render gadgets. Now that we've got an open standard, and shindig is around, many organizations have expressed a desire to move off of gmodules and onto their own gadget servers using shindig, but in order to ease this transition, we need to make sure that some existing things continue to work. That being said, if we can get everyone who is in this situation to agree to migrate to using rpc instead of ifpc, we can probably remove the feature sooner rather than later. Personally, I want to get rid of IFPC right now -- it's slow, bloated, and really hacky, but if we wind up with most of these migrated sites needing to maintain their own local copy of IFPC anyway, it just makes adopting shindig harder.
