Hi folks,
 
We've made some changes recently to live.com that may affect some of the gadgets you are writing.  These changes were made in part to help alleviate some concerns around having 3rd party gadget code hosted in the live.com domain.  What you'll find is that your external gadgets are now each housed in their own IFRAME (more on the implications of this later) in a separate domain (gadgets.start.com).  We considered the idea of hosting all gadgets in a single frame and providing a tab at the top of the page that lets you switch between internal and external modules, but we felt that this solution with individual iframes gives the best balance since gadgets of all types can still be intermingled on the page.  We do have plans to add tabs to let you organize more content on your page, and we didn't feel that adding a one-off tab for this particular scenario was the right solution.
 
Most utility methods will continue to work, such as the parsing routines and utility functions like ObjectToString.  Your gadget will also receive all the same constructor arguments as before, such as p_args.onDashboard, p_args.module, and any gadget-specific parameters that were serialized out using the gadget-level storage method described in an earlier post (here).  The gadgets.start.com domain is cnamed to www.live.com, so all network requests and back-end calls will continue to work as before.  If you are using the Start.Const variables for making network requests, you won't need to change any code for this, as these have all been updated to point to the correct location depending on the domain.  The session id in the live.com cookie is also automatically written to the gadgets.start.com domain before your gadget is instantiated, so you don't need to worry about network requests not having the correct session id.  In general, we've done a lot of work to make sure your gadgets operate in almost the same environment they were operating in before, and for the most part they should continue to work without any changes.
 
With that said, here are some issues you may experience:
 - GetPreference and SetPreference will no longer be supported
 - sizing issues
 - scroll bars in Firefox
 - internal APIs may stop working
 
GetPreference / SetPreference
We've decided to discontinue supporting GetPreference and SetPreference for gadgets due to the performance issues it has now that they are hosted in iframes.  To understand why this is an issue, it helps to understand the iframe approach.  Every 3rd party gadget that is hosted in an iframe is essentially running in a scaled-down version of the live.com framework.  To get the preferences into that frame, a round-trip to the server would need to be made to fetch the preferences for each gadget this is instantiated.  Since the iframe url is on a separate domain, the iframe instance can't interact with the parent application so none of this data can be shared.  The only other alternative would be to parameterize the data on the iframe source URL, which isn't really feasible in this case.  We will continue to support gadget-level storage using the method that was posted earlier.  Note that there is a bug in our ObjectToString code that may cause Out of Memory errors or Stack Overflow errors as the code ends up going into an infinite loop.  Unfortunately, the solution we posted for gadget-level serialization may very well cause this to occur, and we've posted a fix on that thread to resolve it.  If you are seeing this error, please check to see if you are using the updated version.
 
Resize issues
Obviously, with any iframe solution, there may potentially be annoying resize issues.  We've done our best to make this as small of an issue as possible by automatically resizing the iframe to the correct size whenever the gadget content changes.  However, from some of your gadgets that I've been testing, we know there are some corner cases that will need some polishing, so we've added a Resize() method on the p_args.module object to let you force a resize.  If you are experiencing truncation issues, we recommend that you call this Resize() method any time the gadget content changes.  For example, as the result of an network request or user interaction.  Again, this shouldn't be necessary in most cases, but we've provided the method just in case.  Note that we don't currently have a solution for this in Firefox, as explained in the next section.
 
Scroll bars in Firefox
Resizing an iframe from within the iframe content is not currently possible in Firefox, so you will see scroll bars and a fixed gadget height on your gadgets there.  We're looking at ways to make this better, such as including a custom height in the manifest xml that would allow you to specify the preferred height, or adding a drag grip or +/- buttons on the gadget that would allow the user to resize the iframe manually.  We're not thrilled with the scroll bars either, and we're definitely pursuing a better experience.  Please bear with us for now.
 
Internal APIs
Internal APIs, such as DisplayReaderPage, will no longer work since these will no longer have the right context (e.g. there is no reader page in the stand-alone gadget iframe).  We're looking into possible solutions for those of you using methods such as these.
 
One upside to the iframe approach is that gadgets can be tested in a stand-alone environment by visiting the iframe url.  For example, visiting http://gadgets.start.com/gadget.aspx?manifestUrl=url will instantiate only the gadget contents without chrome.  This is helpful for testing memory leaks and for doing other debugging.  We have some cool debugger tools in the works that will let you take more advantage of this as well, such as call stack windows and trace output windows, so stay tuned.

Thanks!
steve

Sanaz, a kick-ass program manager on the start.com team posts about some of the changes we just shipped tonight.  By the way Sanaz is out of control awesome, like seriously.  In a good way.  You know how some people are so enthusiastic that they can just inspire the hell out of other people to get stuff done?  Yeah.  It's like that.  I mean, I'm sitting here at 1am thinking about some of the code I'll be writing for a new feature we want to ship in the next few days and I'm hella inspired.

Some of the changes we shipped tonight are fixes that have been bugging us for the last few days.  You know how the modules would rearrange themselves when you dragged them around the page?  Well, I thought it was a really good idea.  But wow, I haven't been given that much flack about a feature I wrote in, well, well in a long time!  People who tried to figure out how to get the modules in the right place would send feedback saying it was like the towers of hanoi puzzle, or it was like solving a rubik's cube, or they assumed it was some kind of chinese puzzle.  My god people were frustrated.  But it did make some sense in theory.  See, there's this zig-zag pattern, and when you dragged the module you were really just rearranging the order so that we could keep the relevant modules on top when the columns automatically resized, and, um, well yeah.  I guess it was crap.  Anyway, this was one of those things that makes sense in theory but totally sucks in practice.  And we tried it, got your feedback, figured out a better solution and shipped a more usable version just a few days later.  Whew!

Things are moving fast.  We are just getting geared up for some new stuff.  Stay tuned.  Oh, and by the way we're in the process of getting a forum set up for general discussion which is why we haven't done much with the startcom blog.  I'll post a few updates to it anyway since some of you have it on your aggregators.

Back at ya.