Getting back to the original question: In most, but not all cases, I use:
UniVerse => (socket) => .NET Service -> Web Service Where the .net service is not necessarily on the same machine as UniVerse (security/firewalling restrictions). Using UniVerse sockets to drive services is something I do in a lot of my applications (mvPDF, mvDistributor etc.) and works well. I also have routines for calling web services directly over UniVerse sockets, but you don't get the advantages of WSDL import and XML/JSON serialization built into .Net. The CallHTTP stuff is a pretty rubbish set of functions over the top of the socket API and XDOM is horrible so it's easier and more flexible to do your own if you're going that way :) As for the other stuff: we all love the u2 model (or we wouldn't be here) but that shouldn't blind us to the fact that there are areas where the implementation could be improved: indexing is one of those. Using cache better is probably another, but restricted by the fact that this is a multi-process model: caching would be much easier for single process, multithreaded servers that don't have to load shared memory segments to make data visible to all participants. In a replication scenario, for example, being able to replicate directly to a subscribers' cache could have advantages if you don't need the subscriber to guarantee that it has committed to disk in good time (unless it suddenly becomes a publisher/fail-over when it has to sync the cache).. Brian _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users