Noticed this article, posted yesterday, on the .NET development center of the MSDN site. It's an in-depth look at the PropertyGrid control, covering the various attributes and classes that custom controls can use to take advantage of the PropertyGrid as well as details on leveraging the PropertyGrid within your own applications. A "must read" for any developers writing custom controls.

Having done some further research into the previously mentioned Macromedia Pet Market demo, I came across the Flash Remoting Layer which I hadn't seen yet. The features that stuck out most were:

• Parses and translates ActionScript XML objects on the server into an org.w3c.xml DOM, making any remote service (a CFC, a page, an EJB, a Java class, a .NET DLL, etc.) that accepts and/or returns XML documents seamlessly accessible to Macromedia Flash.
• Enables objects to be passed to remote services by reference and by value.
• Access SOAP-based web services directly from Macromedia Flash using built-in SOAP Proxy Adaptor.

Macromedia certainly seems to be positioning itself well...

Yesterday Macromedia realeased a Pet Market demo application to demostrate what they mean with "Rich Internet Application". The site comes in different version with support for .NET and J2EE backends. Even if I'm not sure if I like the graphical design and I don't like Flash as a format, the idea of these kind of front ends are interesting. Hopefully, browsers will soon be stable enough to build these kind of applications easily while still using open, accessible standards such as XHTML, CSS and SVG. [protocol7]

I bet you could build it today using just IE5+ or Mozilla and Adobe's SVG viewer. IMHO, the major thing that Flash has going for it right now, over these standard technologies, is the fact that it has an rich set of tools to create the content. Flash has a full on RAD enviroment. Right now, all SVG has is your favorite XML editor (VS.NET, XMLSpy, TextPad, emacs, etc.) followed by a  browser refresh.

One more .NET weakness.. I was surprised to find that the FCL is completely bereft of support for client side FTP functionality. Bummer. I would have wanted an FTP class that did FTP, Passive FTP and SFTP. Given the very complete support for HTTP this omission was surprising. [BitWorking]

This has been hashed over since the early beta days. While it's true there is no built-in FTP classes, and I suppose that could be viewed as a weakness, the most important thing is that the WebRequest framework is abstract enough to support other web protocols, including one's that haven't been invented yet! In fact, there's an unsupported FtpWebRequest implementation downloadable from gotdotnet.com.

The WebRequest framework enables me to essentially plug any protocol into my application just by making sure I don't couple myself too tightly to any one subclass of WebRequest. When a new protocol comes around, I just deliver the assemblies required for the implementation and add a few entries to my .config file and *poof* my application can leverage it. Granted there may be some things that you want to do a little differently as far as setting up a request per protocol, but as long you make sure your transfer layers are only interacting through the abstract WebRequest/WebResponse interfaces you can setup higher level factories to create concrete WebRequest implementations.