On the new Longhorn SDK, a designer asks, "Does size matter"...
So the debate rages on Hari Sekhar's blog http://weblogs.asp.net/harisekhar/archive/2004/02/10/70864.aspx about the related trade-offs between downloading 3GB of help content in one big lump sum, allowing select pieces to be downloaded, and have nice auto-update features that get the latest help updates right off of the web.
Up to now the debate has been if they should package the help system into small parts so you could specialize the SDK help viewer and only get information on say XAML or Avalon, and not have to worry about WinFS or other platform features you don't give a can of beans about. The trade-off is to probably still have these packages (I'm guessing they are going to need some packaging routine that emphasizes performance), but just download the content all at the same time and allow filters, rather than availability to govern what you see and what sets get loaded.
Now, for the life of me, I want my cake, and I want to eat it to. Ideally, I'd love to be able to have all of the content on disk and have it be as performant as possible. Barring this possibility, then I think it will be imperative to have the partial download options. Furthering this concept, I want to be able to install multiple versions of the SDK veiwer each syncing different portions of the content (again, so I can have all my stuff and still get the full on speed of having only a partial help set loaded in each viewer).
In addition, indexes and content should be held differently, I may want the results of a search operation to return content that I don't have downloaded yet. When I try to access the content, I should get the option to automagically download it for use in my viewer. A kind of placeholder in the content tree should be held waiting for me to go look at something that doesn't exist yet, but could if I so desired. In general this type of fragmentation can lead to some really nice container formats (are they going to use WinFS and get a lot of free services?) that emphasizes grabbing any and all content on the fly if necessary. If I only want C# samples then it only gets that information, if I want another language it'll have to download that information. If I wanted the results of my content to be displayed in Arabic, it should download the arabic version if available, but I should be able to freely switch between English and Arabic. On demand content is extremely powerful, especially when you have a decent web connection.
To wrap-up:
1. Size matters, but people want it both ways. Some people have more space, others have less.
2. No matter what option you pick, I want the maximum performance.
3. If you go to the container formats, can we maybe get the full on-demand system? The loaded index, but non-existent content until it is requested seems very pleasing to me.