Congratulations on your paper re: KnowNow

[Rohit Khare]

Gentlemen --

I was quite pleased to see your latest work from DSTC: 
http://www.dstc.monash.edu.au/awsa2002/papers/Zhao.pdf

Not least, of course, for your valuable analysis and demonstration of 
the basic insights behind KnowNow's technology. I am perhaps even 
more impressed that these ideas shone through clearly enough you 
could construct this _without_ being indoctrinated by any of our 
employees... !

A few of my first impressions:

* You are indeed correct that there is a bit more to converting a 
J2EE app "back" into a real MVC app than sprinkling r/t widgets into 
JSPs. Entire chunks of functionality have to be rewritten into 
"single-page applications" (a rhetorical flourish I credit to 
OpenTibet, actually). The analogy I originally proposed was to call 
our applications ESPs (event server pages) to convey that sense. 
Another idea bandied about was ACPs (active client pages) to make it 
clear that the processing burden was on the client side. Dialing the 
psychic hotline at 1-800-KNOW-NOW clinched it, though...

* The reason I called them microservers was that they indeed were 
intended to be substitutes for the lack of IP-addressible HTTP 
servers on the client machines. By reducing them to a form that could 
be embedded within a document scripting language (DHTML, VBA) and 
punching out persistent connections, we invented a commercially 
relevant transitional technology that simulated real HTTP 
client/server pairs at each node.

*  One explanatory construct that doesn't come through as clearly in 
our current generation products is the role of active proxies. The 
theoretical extension was that rather than, say, directly POSTing a 
new bid to ebay.com's server, you could proxy that through a KN 
Router, which would _also_ POST it to lots of servers sitting inside 
the pages of other interested bidders' browsers at the same moment. 
In essence, I view our technology as a way to attach subscribing 
servers to the _end_ of a proxy chain. See also Microsoft's proposal 
for WS-Routing and very early work at W3C on PEP. And, of course, a 
proxy can be inserted on a subscriber's path that can filter, 
transform, and analyze message flows as well, which is the basis for 
our plug-in architecture for content routing.

* Finally, the essential aspect of our product that has yet to come 
into its own is why we call it a router: multiprotocol support. Just 
as a Layer 3 router works to interconnect various LAN protocols 
(DECnet, AppleTalk, Novell IPX) by internally casting all traffic as 
IP and dispatching it as IP; our vision for an application-layer 
router is a way to connect user applications that speak HTTP, SMTP, 
NNTP, FTP, and so on by upconverting to a protocol that looks 
suspiciously like SOAP. Hence, SOAP Routing. Of course, that's 
another matter for now... I'll be writing more about it in my PhD 
thesis this summer.

Once again, my thanks for your work! Do let me know how we I can be 
of assistance.
   Rohit Khare
   Founder & CTO
   KnowNow
   (on leave at UC Irvine)