WSS v3 and MOSS 2007 SDKs Available (RTM)

by | Jan 23, 2007 | BizTalk Community Blogs via Syndication

[Via Bill Simser] Required for every SharePoint developer:

  • SharePoint Server 2007 SDK
    The Microsoft Office SharePoint Server 2007 Software Development Kit (SDK) contains conceptual overviews, programming tasks, code samples, references, and an Enterprise Content Management (ECM) starter kit to guide you in developing solutions based on Microsoft Office SharePoint Server 2007.
  • Windows SharePoint Services v3 SDK
    The Windows SharePoint Services 3.0 software development kit (SDK) contains conceptual overviews, programming tasks, samples, and references to guide you in developing solutions based on Microsoft Windows SharePoint Services 3.0.

Yes, that’s right: the MOSS SDK includes the RTM version of the ECM Starter Kit!

Update: read the official SharePoint Team Blog announcement here!

Technorati tags: sharepoint, wss, moss, sdk, ecm

SmugMug goes Ajax: Interesting Pitfalls

by | Jan 22, 2007 | BizTalk Community Blogs via Syndication

[Via Thomas Hawk, Techcrunch] (Why do photo sharing sites need to have weird names: Flickr, SmugMug, Zooomr?) People who know me a little bit probably know that I love to take photographs, lots of photographs. My inner geek of course wants to do geeky stuff with all those pictures, so every picture gets: a) tagged and described (metadata stored in the picture itself so you never ever have to type descriptions, tags again) b) geo-tagged (store the coordinates where the picture was taken in the metadata) c) stored for eternity (I have a pro Flickr account, allowing unlimited upload and storage, it’s my off-site backup). Why do I use Flickr, instead of other photo sharing/storing sites? Well when I started (a little over one year ago), Flickr was the only big one that exposed an API. So as a developer I could see my Flickr account as my “picture data store”, accessible via a Services Interface; this means you are never “locked in”, if a feature is not available you can write your own solution (eg batch download). Flickr has a very large community in general, but also a very large developer community: their API even has a .NET wrapper (kudos to the people who maintain this!) and the amount of tools is incredible.

A competitor of Flickr is SmugMug, they don’t offer a free account (like Flickr does) but their feature set is richer. Things that I like about SmugMug, compared to Flickr: customizable home page layout (“web part” style), themes, hierarchical structure of albums (albums in albums, aka as sub-sets) and they use Google Maps instead of Yahoo Maps. I don’t have a SmugMug account but I had a (free) trial account so I could play around with it. The price is right ($ 39.95 per year), but the main reason why I choose Flickr was their API and community.

Somewhere last year SmugMug however added their own API too, and this week they added some really cool features: speed, beauty and brains. The geeky translation for these features is: they switched from the “traditional” HTML user interface to an AJAX user interface. So no more page reloads, no more scrolling, better speed, nifty slide out effects and so on. Job well done SmugMug team! Don MacAskill (the SmugMug CEO and Chief Geek (I’d love to have geek on my business card!)) blogs about the latest release. He mentions the obvious advantages, but (more interesting) he also describes the less obvious pitfalls of this switch. Although these pitfalls apply to SmugMug, they could apply to all the sites switching from HTML to Ajax UI’s.

  • Search engines. I know Google’s been testing a more JavaScript-aware version of Googlebot, but how aware it really is is anyone’s guess. Certainly no crawlers I’m aware of do even a marginal job of crawling AJAX pages. But our customers spend tons of time captioning, describing, and keywording the 120+ million photos at SmugMug.
  • Backwards compatibility. We built our URLs from day one to be “permalinks” so they wouldn’t change if you used them in your blog and forum posts. We had to make sure that things still worked going forward.
  • AJAX Permalinks. Now we needed new permalinks that describe various pieces of data for browsing SmugMug, but we also needed to keep them short so people could copy & paste easily, so they wouldn’t wrap in emails, etc.
  • Stats tracking. Specifically external sources like StatCounter and Google Analytics which only track page views, not JavaScript UI interactions. Our customers, especially the tens of thousands of hardworking Pros who build their photography businesses at SmugMug, expect to still get useful and meaningful statistics on who’s viewing what.
  • Browser interfaces. People expect the Back & Forward buttons to work properly, along with History and Bookmarks. Doing so in all three major browsers was thought to be impossible, and we failed many times. We solved this one, and this was the last biggie. I believe it’s an internet first. Jimmy will be updating his blog about exactly how we do it so anyone else can follow suit. It’s good for the web as a whole for this stuff to move forward.

So I hope Flickr is going to follow the lead SmugMug has taken and add some of the fancy SmugMug features: their community is begging for them (Flickr is know to implement new features very, very slowly because they have to keep up with their ever growing user base and storage/performance requirements). Or maybe it’s time to give SmugMug a chance, the only problem is that I will need to upload all my photo’s (almost 10.000) once again… to be continued!

Technorati tags: flickr, smugmug, photosharing, ajax, api

Did you know?

by | Jan 22, 2007 | BizTalk Community Blogs via Syndication

Did you know?
The default XMLReceivePipeline does not validate the structure of the input XML message. Based on the MessageType of the input message, it will try to lookup a document specification (schema) and if it finds one, will do all the required property promotions / distinguish fields as specified in the schema and also promote the MessageType.
If there is no schema deployed in BizTalk that match the MessageType of the input message, it simply throws an error as shown below.

Finding the document specification by message type <MessageType of the input message> failed. Verify the schema deployed properly. 

On the other hand, if you are using a custom pipeline with "XML disassembler" component and you have added your schema in the document schemas collection, it will check to see if the MessageType of the input message match any of the schemas specified in the Document schemas collection ONLY, if not, it will throw an error a shown below.

No Disassemble stage components can recognize the data.

Note that, this error occurs even if you have a schema deployed that matches the MessageType of the input message, but is not available in the Document schemas collection.
The above is obvious / expected behavior… this is just a refresher.

Benny Mathew
Seamless Integration Solutions
BizTalk Consulting, Development, Training
Bangalore, India
Cell: +91-9945602604 / Office: +91-80-41676177
http://www.seamless.in
http://GeeksWithBlogs.net/benny