Centaurs Identity
Random thoughts in my brain
PDC: Yukon loves XQuery
Killer XML storage is coming that is Yukon.  It's got XML indexing feature built-in, as well as XSD validation feature, and XQuery extension for XML data modification.  It looks promising.  For XML heads, storage for XML traditionally files.  It is because of this "file-ness" nature that people overlook the fact that elements and attributes are more important than tags and whitespaces.  It is because of this "file-ness" nature that people tend to give too much attention on how to encode those elements.  If Yukon would be the killer InfoSet storage, people would look more on information items than those wire-formats related staff.
PDC: Today's photo
This sign is in front of almost every room I went:
 
 
... and therefore, this should be happened.
 
PDC: Doug Purdy, my love
Doug Purdy's serialization talk started with full of enthusiasm.  Lots of expectations were in the room, and Doug Purdy and the successor of XmlSerializer did not disappoint us.  Since I am really tired and have to sleep, I post some keywords Doug showed us today.
 
- BinaryFormatter is now version-aware.
    There will be new attribute temporarily called [OptionallySerializable] to tell BinaryFormatter that some previously serialized data does not have values for fields.
 
- The new XmlFormatter is really an InfoSetFormatter.
    But Doug, InfoSet has [encoding] property... ;-)
 
- [DataContract], [DataMember] is the new way to tell we want to serialize some member fields of some objects.
 
- [OnDeserializing], [OnDeserialized], [OnSerializing], [OnSerialized]
    Are those attributes indication that interfaces in OOP not applicable to the real world programming?
 
- SerializationContext.Current.KnownTypes.Add and "base type aware schema generation"
    Serialization is really what they do to maintain those nature of type system.
 
- "wsdlgen.exe /server" now can process "every" and he means "every" XML Schema.
    Anonymous types inside element declarations, no problem.  I heard someone (I am sorry I forgot his name.  He was introduced as a Dev. Lead in Doug's session.  I have to thank him) that it even solves the problem called "choice of sequences".  How those constructs are turned into C# code?  Well, if it is supported to be [DataContract], it will.  If it won't, then wsdlgen.exe will try to do it itself.  If it can't, then we will get parameters typed Message, which is XmlReader.
 
- System.Serialization will not last.
    Doug and his teammates' efforts on this namespace survived in the PDC bits, but will not likely in the Beta 1.  He told us it solved 96%, but they throw them away.  What a courage.
 
And for the last, but definitely not least, Doug taught us that Serialization is what we use to serialize and deserialize between CLR and stream.  It is not another way to program against XML.  For XML programming, we have plenty of staff in WinFx, like XmlReader and XPathNavigator.  Those are not serialization.  If you love XSD and can't live without substitution groups and choice of sequences, you will live with XML programming model in the WinFx.  If you want serialization, you are concerned about CLR.  They have [DataContract], [Serializable] and ISerializable for the purpose.  Let's repeat:  Serialization is for CLR, not XML programming.
 
Finally, Doug told us that if COM is love, Indigo IS love because every developer including asmx lover, EntrrpriseServices lover, and Remoting enthusiasts will love Indigo as the successor of their beloved technology.  I am thinking on this topic, and will post my opinion later.
 
I really fell in love with Doug (don't worry Doug, I'm straight) this evening.  He is my most favorite speaker so far.
Please fix this inconsistency
We have http://schemas.microsoft.com/2003/xaml and http://schemas.microsoft.com/winfs/2002/11/18/schema. Shouldn't it be http://schemas.microsoft.com/xaml/2003 or http://schemas.microsoft.com/2002/11/18/winfs/schema?
 
I have to ask one more thing.  Did Microsoft decide namespace versioning is the way to go?  XmlFormatter did not seem to like the way anyway...
PDC: Scoop on Indigo and WSE2 relationships
Don has just ended his first talk today.  Don said that Indigo programming experience is more like the asmx experience we are used to today, than Remoting and ES experience.  He showed us some code, and it is indeed like asmx.  We have [Service] and [ServiceMethod] instead of [WebService] and [WebMethod].  But wait.  There is a programming model that alike the one in Indigo even more, and its name is WSE2.  In fact, WSE2 messaging based service seems at least for me almost the same in spirit as Indigo code Don Box showed us today.  It is still in TP status, but I guess those who can't make the PDC but would like to feel some kind of Indigo wave should have WSE2 TP now.
Longhorn run on my VMware 3.2!
Longhorn on VMware Don and Chris's Demo Repro-ed on VMware
Quick note to use VMware. I had to turn vmware service off after installing VMware tools. Vmware service handles mouse pointer in-and-outs, but it does not work correctly. Installing VMware tools will fail because its SVGA driver is not signed. But you can install it manually from Control Panel - Display Settings.
Here are source files.  You only need to install Longhorn PDC build only.  MSBuild.exe, referenced assemblies and other staff is there by default.
 
Here are some photos of today.  See the Senior Executive is really coding hard.
Don Box, Chris Anderson, and Jim Alchin on Longhorn Jim Alchin coding hard.
 
Yes, we are having fun so far!
PDC: Indigo... THE message bus
I attended three sessions after Bill Gates' keynote and Jim Alchin's general session.  They are all 200 level talks, and the overview about Avalon, ASP.NET Whidbey, and Indigo respectively.  As an XML and Web/Services (now they spell like this) guy, I was really looking forward to seeing some more deep Indigo staff than the bits demo-ed by Don and Chris.
 
Actually, there were few to "see" in the Don Box's Indigo talk.  But I "see" many things that was not clear until today.  His four tenets are just what I had to write for my article (published in Japan).  Those are:
- Boundaries are explicit.
    The "seamless from inproc to x-process to x-machine" story is over.  We have to recognize boundaries just like we do in the real world.
 
- Services are autonomous.
    Our service has no impact if your service crashes.  Your processing time does not matter our transaction system.
 
- Share schema, not class.
    Objects/Classes encapsulate data and behavior together.  Sharing classes means we need to share type system, deployment models, and/or programming languages.  Since we have already seen DCOM/CORBA/RMI failed, we have to understand that requirements are too restrictive for most of distributed scenarios.
    Services share schemas for data structure and contracts for behavior.
 
- Policy based compatibility.
    Since we don't share classes, we don't use type hierarchies for compatibility.  We use policy (think about WS-Policy).
 
There were a scene to see, though.  When Don called someone in the front row and Mr. David answered, Don told us by using his body movement what was that about integration in the DCOM era and how boundaries are important to remember.  That body movement reminded me Don's TechEd 2000 talk about COM+ Services.  I don't precisely remember what was that, but he told us that we have to tell our wives that we should implement some COM interfaces (free threaded marshaller perhaps?) so that we could feel integrated better each other ;-).  FreeThreadedMarshaller was sensitive to COM+ context and did not work with x-process scenario, but still, it enabled us ignoring the COM+ context boundaries.
 
Anyway, THE message bus will be there, hopefully soon.  And let's not forget the fact that Don told us two things.  First, we should use asmx to prepare for Indigo.  EnterpriseServices can be used, but Remoting has no future.  Second, and this is not that I am confident what I heard, but Indigo will run on .NET Fx 1.x.  Indigo will run on XP, and 2K3 too, as well as Longhorn of course.  Is this really what I have heard?  Any PDC bloggers?
PDC: Task one is done
I am waiting for the Indigo overview session to start.  ScottGu did great talk about ASP.NET Whidbey along with the great demo, and as a result, he's got lots of questions afterward.  Because there were LOTS, the next speaker had to wait for a while, seated next to me.  That was a good chance for me to hand in the gift I brought from Japan for him.  Surprisingly, I had to write my autograph on the gift (it was the translated version of his book).  Thank you again for the great book, Don.
PDC: Selecting sessions to attend
It is Sunday morning.  This is the first day in my life that has 25 hours (Am I correct?).
 
PDC is here.  This morning we will receive our conference bags and goodies.  Pre-Con sessions will also be held today, followed by some BoF sessions, none of which I and my wife will attend.  We have to get over jetlags today (it is 4:30am at LA, 9:30pm for me).
 
PDC commnet site has already been ready for some slide decks.  I have downloaded some of them to help organize my schedule.  Even Don Box has already uploaded his slides, quite amazingly.  Still, I need to know how to copy myself like ex-agent Smith.
 
So, we are ready to have some fun!
It is coming closer...
Ingo Rammer have already landed at LAX.  We have 33 hours to go.  Lots of work should be done before we finally reach to the gate, but I can't settle to work...
 
I and my wife will land at LAX on 24th.  We have meetings on 25th.  We will have spare time on 26th (we have not regi-ed for the pre-con).  So, we have almost three days to get over the jet-lag.  From 27th through out the whole week, we will not be able to sleep anyway because of the excitement we will get, I believe.
 
See you there!
Hello Kotomi Rachel
Congratulations Drew!
We will have the Japanese PDC
We will have PDC highlights in Japan.  However will it be, I will go fly to the LAX.
 
Since we will surely have plenty of things that will be talked at the PDC LA but will not be talked at the PDC Tokyo, I will consider holding guerilla BoF (it will be guerilla because they will not allow us any room and time frame...).  Titles like "Top 10 features that are not in the current VS.NET but will be in Whidbey" sounds attractive.  Demos can be created using PDC build of Longhorn and Whidbey and Indigo and so on.  Lunch time should be good for it to happen.  The place... will be anywhere near some partitioning panels in the session room. 
 
So, anybody interested in doing this together, please contact me(you can write in Japanese).  Don't forget that you will have to pay for the PDC Tokyo to attend this guerilla BoF.
More on Word and Excel as CLR hosts
Prepare the following C# code.  Notice the assembly-level attribute:
 
[assembly: System.ComponentModel.Description("OfficeStartupClass, Version=1.0, Class=Starter")]
public class Starter {
public void _Startup(object application, object workbook) {
  System.Windows.Forms.MessageBox.Show("Hello, world.");
}
public void _Shutdown() {
  System.Windows.Forms.MessageBox.Show("Goodbye, world.");
}
}
 
Compile the source code as "Starter.dll" and place it in the C:\Temp\bin folder.
 
Open up Excel 2003.  Save the default workbook as C:\Temp\Helloworld.xls.
 
Select [File] - [Properties], choose [User Defined] tab (note that since I'm using Japanese version of Excel, the word may be different).  Create two new properties with the following values:
 
Name : _AssemblyLocation0
Value: C:\Temp\bin
 
Name: _AssemblyName0
Value: Starter
 
Save the workbook again and close Excel 2003.
 
Open Visual Studio Command Prompt and type the following.  You know why we have to do this because I have already mentioned about the fact that Offce make little account of MyComputer_Zone evidence:
 
caspol -u -ag "All_Code" -url "C:\Temp\bin\*" FullTrust -n "Starter"
 
This will create new code group for the CAS.  Check out the .NET Framework Configuration tool about this.
 
Now open up Helloworld.xls and you will see the message box.  Excel 2003 can load an assembly from web server location or UNC location, too (a.k.a. no-touch deployment).  Smart client will rock the world!
 
P.S.
If you are interested in writing Office solution, then you must check out Visual Studio tools for the Microsoft Office (VSTO).  It makes creating solutions much easier.
Another CLR hosts were shipped from Microsoft
Office 2003 made its appearance.  It includes Word 2003 and Excel 2003.  The buzz is on about the XML support provided by them and the other member of the Office 2003.  However, there are other important feature of the two.  Word 2003 and Excel 2003 are yet another CLR hosts.  They host CLR if the document they load has specific properties set.
 
For CLR hosts, the most important work to do is to set up AppDomain for managed code to work.  Word 2003 and Excel 2003 will set up two AppDomain, and managed code behind documents (.doc and .xls) is loaded into the second AppDomain named after documents' file name.  It is interesting that Word 2003 and Excel 2003 hosts make little account of Zone evidence.  Managed code behind documents all have to have FullTrust to work.  And if the code has FullTrust only because the assembly has proper Zone evidence, then it will be neglected.  The AppDomains Word 2003 and Excel 2003 create need stronger evidence to make code work.  I think it is because Office documents can flow over network by means of e-mail attachments.  E-mail attachments will be opened up from the local hard drive, meaning they will have MyComputer zone evidence.  Therefore, Word 2003 and Excel 2003 should not trust the code only because they have MyComputer zone evidence.
 
The question that is not solved is how Word 2003 and Excel 2003 make that constraint happen.  Does anyone from Office 2003 team has their blog?