Hi Brian, This looks good, but I have a few comments / suggestions:
- I think it's best to leave off the closing ?> in pure php files due to the common trend for text editors to add trailing newlines. New PEAR code is using this and it's really eliminated a lot of frustration with the code base, and to the best of my knowledge all common IDEs and text editors handle this correctly now. - Is there any compelling reason not to standardize on PHP5? Being able to take advantage of SimpleXML alone usually makes it worth the upgrade. PHP has been officially slated for end of life in 2 weeks, and not even security patches will be issued after August 2008 ( http://www.php.net/index.php#2007-07-13-1) - You shouldn't have to worry about the initial JS wiring, other than passing in some initialization parameters now that the new JS has been committed. In particular, you can ignore all of the _IG_ and other legacy igoogle functions and refer directly to the new gadgets.* packages. There are still a few missing pieces at this point, but those should be committed after the holidays are over (and Zhen and I have commit access to svn and can push our latest changes back). I've written a legacy wrapper to point the legacy IG cruft to the new, cleaner gadgets API to allow existing gadgets to continue to work. - __MODULE_ID__ is actually a hangman variable just like __MSG, __UP, and __ENV variables, so creating a variable named __MODULE_ID__ won't work 100% of the time (specifically, it won't work when the gadget author used __MODULE_ID__ to generate a uniquely named object). I'll be on and off over the holidays, but I plan on making some significant Java and Javascript contributions if I get commit access. I'd be happy to help on the PHP side as well. I have some useful pieces that I wrote before we even started talking about Shindig that I can contribute if you want to take a look. Thanks, ~Kevin On Dec 22, 2007 8:17 AM, Brian McCallister <[EMAIL PROTECTED]> wrote: > So I just checked in a semi-functional server side implementation in > PHP. It needs a *lot* of work, but following Stefano's advice that bad > code is better for nascent open source projects than good code... here > it is :-) > > -Brian > >
