On Wed, Feb 20, 2008 at 8:52 PM, Kevin Brown <[EMAIL PROTECTED]> wrote:
> 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.jsfile > -- 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. > So this is a very interesting comment you have. How many containers out there are really trying to do this? I*f any container on this list is trying to migrate from gmodules to shindig please let us know.* Alternatively, perhaps we can ask some other lists, or put a question on the shindig website asking for container users to announce themselves. I sorta agree with Paul here in that we should be moving faster and not waiting around for these legacy things. If google needs to maintain its own stuff separately, that's fine, but shindig shouldn't be hindered. I also have the same sort of feeling with the php stuff. The only reason we have out of date js files in javascript/* is because we were waiting for the php stuff to catch up. I know Chris is working on completely new stuff and besides that, the code is abandoned. I would really like to see us keep refactoring on the js/java side without having the completely out of date code hold us back. People are starting to get confused about how io.js is different than io.js :) Just my two cents.. - Cassie > > 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. >
