If building a webpart for SharePoint Online is your goal, you should look no further than the mantra no assemblies required. I did a post by that same title where I speak of assembliless internet widgets that are essentially lightweight javascript widgets which essentially pass a few variables to a secondary server.  As the move to the Online space with Azure and SharePoint and Exchange online.  I expect to see partners and developers trying and wrap their head around this space.  So far, I haven't seen anything impressive in terms of integration and real development in the hosted space.  (LiteSuite, is a noble attempt at seeing SharePoint facebook integration, the charts look nice but it's so new I haven't heard about it yet.)  I'm hoping this will kick off some thinking.

"Path to SharePoint" has some great  techniques like modifying the CSS and shows proof with live sites for example to shrink a month calendar and scale down the SharePoint Gantt view, but that is the designer mentality.  Kudos, don't get me wrong, it is impressive!  I know I've seen paid for Assembly required versions of the same thing!  Here's the architects path to the same thing in an infrastructure solution.  Essentially when you have to build an assembly it finds a home, but the processing takes place elsewhere and the data passes... where there's a will, there's a way.

Cloud Based Logical Architectures

Understand that the logical architecture is

1) The User loads a page on a blog, SharePoint site, or Facebook page

2) The Facebook, SharePoint online or blog server attempts to compile the page and the gadget, widget, webpart or page elements are built external references are requested

3) Behind the scenes the clientside Javascript, flash, silverlight reference in the web part requests the .client side code snippet passing user and session variables to the API on the App servers behind the scenes. 

4) The parameters, user variables, etc... are used to proxy to gather integrated datasources over SOA, webservices, WS- identity systems, etc... to provide the data or

5) Data is passed back to the Facebook, SharePoint Online, and generic blog

6) Seemless HTTP content is passed to the client

Example of Snippet Generator from Widget Box

Use chooses colors, account information, sizing, etc... and then chooses embedding options.

Let's say I wanted to add a twitter feed to my site.  Now we know that we go to places that build gadgets and widgets and we can throw them on our sites, but what if you were the first?  Twitter has a rich API.  You could do what widgetbox and the others do and write the code and then do like they do and share just the client parameters like the username.  Here's one of those examples.

Widget client side code in Flash

Don't want flash... you want the same example with Javascript (all the work is on widgetserver.com and the user adding the code doesn't have to ring up the admin...)

Slick huh?  To get this...

Example from: http://www.widgetbox.com/widget/twidget

Check out Widgetbox.com as a great example of community evolving around their widgets.  The slideshare.net is more of another good example of the assembliless rich functionality that is a no server side footprint.  I was so impressed I uploaded a few decks.  http://www.slideshare.net/joeloleson

Here's a snippet of what they are doing...

Let's analyze the Snippet above.  This is a very clean completely transparent flash component that passes parameters and runs from slideshare.net.  It passes variables on the size, the buttons, and look and feel, but the player and all of that hard core proprietary stuff runs from their boxes.  They don't give anyone their compiled or uncompiled code.  It's beautiful and clean to the SharePoint admin on this box.  It renders a very rich experience. and renders like the sample below.

I think if Developers could grasp these concepts and would start thinking like this, trying to build minimal footprint apps, and where they build their apps tight and with seemless integration into SharePoint with a lightweight client side footprint leveraging a simple javascript "include" mentality with flash, a simple reference passing relevant parameters, even silverlight dropping a bot, the interaction could be as rich as the developers desire and they could manage them the way they want to manage their code... separate from SharePoint.   (Remember this is cloud not intranet.) This is particularly important in the hosted space, and now the sky is the limit when you think of who can consume your cloud service when you build your webparts and gadgets.  Now when you build your gallery, it isn't a local consumption the world is yours.  As developers move to the hostel model way of thinking I think you'll see less arguing about modifying custom site definitions, because you won't be able to touch them.  You're also much more likely to find a host that will host your aspx pages and assemblies in an isolated while still multi-tennant than you would find a hoster who wants to put your assemblies and code with your SharePoint sites.  Does it restrict what you can do?  Try to think outside the box... Think in the cloud!

P.S.

Phew, I think I stretched myself a bit on this one, so sorry if it hurts.  I hope it does give you a different perspective and make you think differently about things.  Enjoy.

Joel Oleson