''(Moved from DoItFramework)'' I think that more recent MicroSoft ideas on browser/web-system-application integration could be used to support the implementation of a system metaphor like this. MicroSoft has been extending UniformResourceLocator? (URL) concept (with IMoniker) to include access to any content that can be hosted in a visible area -- not just web pages. You can see this in the way that you can open file directories and Office documents within InternetExplorer?. ''Microsoft ideas? What on earth are you talking about? URLs have always explicitly supported more than just HTTP. Mosaic let you poke around your filesystem and open files with the correct application back in 1993; I don't even know of any Web browsers that don't. I don't know about IMoniker in particular, but a good rule of thumb is to run screaming from any extensions Microsoft makes to standard protocols (or schemes, in this case). --GeorgePaci'' In theory, you should also be able to make application forms/pages available from URLs, even without a conventional web server. (...though a web server, with thin client JavaScript or VbScript would probably be best for inter-system data distribution.) [On the client side, a web browser would be great, although I have yet to convince myself that javascript, style sheets, and absolute positioning go far enough to support a virtual, 3D worktable presentation.] So, for a concrete example, a given ActiveServerPage (URL with ".asp" extension) would be the "document form" for "customer master" information, and parameters (like "?custid=62643") would specify what customer to display. [Content above is unsigned; please feel free to change it.] Perhaps I'm talking about implementation details too quickly, but I thought I'd throw this out for comment. -- JeffGrigg Thanks Jeff -- never to soon to think about implementation details. I try hard, at the start, to not limit a design to that which I can implement. (Like the admonition to a salesmen "Don't confuse selling with delivering", my variant is don't confuse design with implementation.) But I do very quickly reach a point where I need a (gross) implementation strategy in my mind in order to validate the reasonableness of the approach. Assuring myself that someone (not necessarily me) could make it work is important. It would be nice to keep things open, without relying on capabilities available only on a commercial OS. I am too often attracted by nice MS solutions -- I just don't know if that belongs on a "What I Love, or What I Hate About Microsoft" page. If one was serving business "forms" as a special kind of web page, I think the idea could very easily transend MicroSoft products: With the right standards and conventions, you'd need to have a specialized "business forms" browser, but the server side could be supported on many platforms by many vendors. -- JeffGrigg ''This last comment (and maybe the whole idea) makes me think ExtensibleMarkupLanguage (XML). And although the XML experience has certainly made some things (integration with other systems, separation of view from presentation, or of one level's view from the next level's) easier, it hasn't yet revolutionized the whole idea of writing applications. Incidentally, the other DoIt project is one of the examples mentioned on the XML page.'' -- LeighCaldwell Re XML: there was a interesting paper discussing the cons of XML http://www.interlog.com/~gray/markup-abuse.html referenced by Jon Udell on his joncon Byte news conference http://www.byte.com/nntp/joncon?comment_id=5779#thread Before reading that I had assumed that XML would probably play a large role in any implementation; afterward I at least decided that an XML approach deserved more thought, and at least was not a "gimmie". --JimRussell