August 2003 - Posts
Not happy with your vanilla windows shell? Joe User has all the info you ever wanted to know and a bit more on shells.
New WS from MS:
The Microsoft.com Web Service is an XML Web service that will enable you to integrate information and services from MSDN, Technet, other Microsoft.com sites, and Microsoft Support. As a way to test the new architecture, we present version 1.0 of the Microsoft.com Web Service, which allows you to integrate information about the Microsoft.com top downloads. Future releases will build on this architecture to provide access to a broader variety of Microsoft content and services.
More info here.
I was reflecting on John’s “RSS for Sensors” entry. The first thing that came to mind was load on the network. That is, how often would each sensor be polled and would the polling flood the network. In this case is high frequency a problem?
An alternative is a registration/subscription system. In this case the RSS reader could be notified when a message was available. Each sensor could deliver its feed to an intermediate server to hold the feeds and manage the notifications.
The intermediate server scenario could also work as a simple “feeds” container. All sensors can deliver their feeds to the “feeds” server. And all sensor clients could periodically poll the “feeds” server.
Another issue to consider is trust. Can the feed consumer trust the feed as authentic?
What are other issues?
Following up on John’s and Dan’s entry. I originally choose the Dataset for ease of programming and maintenance down the road. The alternative was to use the DOM but the syntax made for pretty ugly code that would be hard to decipher beyond the original author.
Another issue was joins. In the end, when working with XML, you need many of the attributes of a database. The Dataset gives database like functionality for free. I liked XQuery /XQL better but as Sakda has pointed out the dominant code set has not been decided.
In the end everything considered I though the Dataset was the best solution at the moment. However, I have had a couple of concerns since. The first is performance. The Dataset serializes the entire document every time. For reads XmlReader would be best and for writes XPathNavigator.
A database like layer of abstraction that used XmlReader, XPathNavigator, and XQuery/XQL would be best. The abstraction could put a pretty face on efficient XML manipulation. My concern would be to recreate a part of Whidbey, Yukon, or even Longhorn. One of the PDC sessions is exactly on this subject, “Yukon: XQuery, XML Datatype”. Makes sense since MS must have run into the same issues.
We should get Whidbey and Yukon shortly and a Longhorn beta after PDC. Ahh, the promise of a brand new day :)
RSS readers review from extremetech
A number of RSS libraries are emerging. RSS.NET is an open source library that is compatible with RSS versions 0.90, 0.91, 0.92, and 2.0.1. Another one is RSS Magic for .Net (shareware).
Requested a spotlight and created a pretty page for the blogs.
Command notice is online.
-abel
Ingo echoes my sentiments:
If you want to improve your application's scalability and robustness, you should not think about objects as the boundaries of remote communication. At the wire, there is only a message and at the other end there is just some piece of software which reads the message and acts on it. The mapping to objects exists merely to increase convenience for developers. As an application architect you should instead think about the exchange of messages.
Updates on CBS
- Pretty redirect in place
- Alpha notice in place
- Documentation in the works (via Anamika)
- Reset password in the works (via Andy)
- Images have been removed from the tabs until the path issue is resolved
- Short name in the works (via Abel)
- EULA style license in place - create blog form
Ching-Huei points to WordNet, and electronic lexical database. I wonder if some of this research can be applied to the search scenarios of speech processing that Deepak is considering. A similar problem exists is mining blogs.
Ching-Huei/Sakda, is there a repository for ESD’s design documents. How about the working documents? What is the feedback cycle?
Deepak proposes:
- screen capture
- audio capture
- speech processing
To create what John and Alex call “geeko” blocks – better known as HOW TOs. Media is tough due to support costs and hardware requirements. However, if desktop speech processing is possible there are some interesting possibilities for video search and knowledge base.
Dan hints at the costs of abstraction. A common class system for the XML portal module communication points in the direction of past object technologies.
One of the insights of service oriented architecture(SOA) is that the power of SOA does not come from the services themselves but instead from how the services are composed into new applications.
Small, robust, well designed services can perform tremendously complex tasks as a group. The simpler the service the lower the tax on the service consumer. The limitation is the ability to model the messaging routes through the service fabric application. At the same time simpler components lower the cost of maintenance. The abstraction boundary forces a cleaner encapsulation of functionality and replacement of a service (thread) is more modular.
I would argue that it is much easier to manage change in the composition of many small web services who share few well known abstractions than it is to manage change in varying abstractions exposed by the same set of services. In the former the difficulty lies in composing messaging routes. In the latter the barrier lies in propagating the knowledge to consume each abstraction.
The tradeoff can be labeled ‘Fat Versus Thin”. In one case the service is “fat”; the service has heavy built in logic, many abstractions, and many interfaces. In the “thin” case the service is minimal, has few and well known abstractions and interfaces, and complexity is pushed into the connections.
Here is a crazy idea. What if each component on the rendered page was simply a web service call that returned HTML?
On the “read” case, the service could be sent an object with the portal metadata, like roles, and the service could return an object with the html to be rendered. The object could look something like:
class WSObject
{
PortalMetadata meta;
Object container;
String XmlContainer;
}
In practice, everything could be simplified and passed as an “object” type.
In the post case, when a user posts a form, communication with the WS could also be packaged into an object. The object would contain the UI component as posted by the web user.
To separate the presentation layer the web service would need another service to generate the presentation output. Using this approach the service can remain generic and each presentation type can generate custom UI.
One of the first issues that comes to mind in this scenario is flexibility of UI.
An afterthought: the separation would also add a layer of security. There would be no need to verify code that the third party code was “nice”.
Andy considers “algorithm for determining the value of the blog“.
WSJ just wrote about Teoma on this subject. Teoma's advantage is that rather than relying on a page ranking algorithm to determine how to list search results, it uses an algorithm that reveals the Web "communities" around a particular topic and what they're currently discussing. So that if you searched on "power blackout" on Friday, Teoma's "refinements" section (on the right side of the screen) included "electrical surge" and "cost of downtime." "It's a great way to learn about a topic, or to find the precise thing for which you are looking, without having to actually go to a lot of links,"
Career advice by Focusing on the first derivative.
In the link below, John Hargrave goes to great lengths in an attempt to get his credit card receipt signature rejected. Unfortunately, he is unsuccessful; but the many and varied attempts sure crack me up! http://www.zug.com/pranks/credit/index.html
I though I would share the blogs I find technically interesting.
Chris Brumme (CLR architect), the content of this blog is almost textbook quality.
Don Box, enough said.
Suzanne Cook, .NET CLR loader notes
Lutz Roeder, really great tools like reflector
Dan points out important directions on the portal architecture. XML, HTTP, plus SOAP give us the current platform. The next step is web service enhancements, there is a lot of good work being done by Don Box' group in this area. The extensions and specifications address security, distribution, reliability, and other goodies.
The R-S-S aggregator is also a good point. In a way it is similar to QuickLinks but the content is dynamic.
MSDN Magazine entry by Jason Clark on
generics.
Microsoft is taking proposals for a one hour session at PDC. For more information see
Birds of a Feather.
I plan to blog about educational technology, distributed software, and XML architectures.