Good idea Cassie. You could make the feature for the old opensocial api depend on the latest version and include that along with a small wrapper file you're talking about. This would allow you to keep the latest OpenSocial code as clean as possible, relegating legacy support to a separate file.
On Jan 29, 2008 12:54 PM, Cassie <[EMAIL PROTECTED]> wrote: > On Tue, Jan 29, 2008 at 12:39 PM, Paul Lindner <[EMAIL PROTECTED]> wrote: > > > On Tue, Jan 29, 2008 at 12:20:08PM -0800, Kevin Brown wrote: > > > On Jan 29, 2008 11:41 AM, Paul Lindner <[EMAIL PROTECTED]> wrote: > > > > > > > So are surfaces gone gone gone? I see they've been totally stripped > > > > out of the 0.7 spec, and now have been removed from the Shindig > > > > OpenSocial-Reference module. > > > > > > > > Can we bring them back and at least deprecate them for 0.7 and > remove > > > > in 0.8? > > > > > > > > > They're not gone, they've just moved to gadgets core. gadgets.views is > > what > > > you're looking for ( > > > > > >http://code.google.com/apis/gadgets/docs/reference/gadgets.views.html). > > > > Yes, I know about this. > > > > How about I rephrase my request: > > > > "Please reimplement the 0.6 surfaces API for 0.7 on top of the new > > views feature, marking the API deprecated in the process." > > > > > John (fargo) is working on getting the shindig implementation > > > working correctly. > > > > As we try to get developers to upgrade to 0.7 it would be helpful to > > allow a cleaner upward upgrade path by deprecating functionality > > before removing it. At the very least javascript calls should not > > bomb, causing the entire app to die. > > > > Of course another option is to freeze opensocial-reference for each > > API release. Perhaps we could create seperate features directories for > > > > opensocial-reference-0.6 > > opensocial-reference-0.7, > > > > instead of just 'opensocial-reference' > > > > Up till 0.7 we were not doing any clean deprecation management because the > apis needed to change so rapidly. From 0.7 on (because containers are > going > to start having fully public launches) we will be managing this more > cleanly. But, anyway, that is a spec issue :) > > This versioning of the reference though, that is completely shindig, and > we > can definitely do it. That is my fault for thinking we could update to > 0.7quickly. (it should be pretty trivial for the container to do) > > The only thing that sucks about this is that the code is 99% the same, so > we > are going to have nearly duplicate copies around. Also, how many versions > back should we support? > > Something that I've been thinking about is possible just a > opensocial6to7.jsfile. This js file will just map all of the old calls > to the new ones. (so > opensocial.makeRequest would be defined to just point to the new method) > > I like this a lot for many reasons. 1, we don't have duplicate code! 2, > anybody can just drop in this upgrade js file on their site to support > multiple versions. 3, if a container doesn't support the old version a > gadget can import the file themseleves. 4, it gives developers a very > clear > code based guide to updating their gadget to 0.7 and beyond. > > We would have one of these files per version change (6-7, 7-8 etc) > > What do you think? > > > > > > > > > Right now developers are complaining that we're breaking things in > > every release, and this just makes it harder to get traction with > > these people. > > > > -- > > Paul Lindner > > hi5 Architect > > [EMAIL PROTECTED] > > >
