On 8/21/07, Andrew Lentvorski <[EMAIL PROTECTED]> wrote: > Bob La Quey wrote: > > On 8/21/07, Andrew Lentvorski <[EMAIL PROTECTED]> wrote: > >> I stand by my NAT hole punching test. If you can't use the framework to > >> do that, it doesn't have enough flexibility. > > > > Other than a narrow band interpretation of the term URI I cannot > > see why you are being so dogmatic, Again it appears you miss or > > do not understand the main point. > > The point is this: > > Where does the abstraction leak? JXTA meet NetKernel. > > Any system that says: "All resources are the same. You access them from > a unified space." has an abstraction problem. Period.
Agreed. But that is _not_ what NetKernel says. There are different kinds of resources with different spaces. The URI abstraction allows for that, which is not often understood or used. A different mechanism is used for resolving an http address as opposed to other schema. The mechanism used to resolve a URI associated with low level machine access schema is _not_ the same as the DNS mechanism used to resolve http. The transports are also different and thus handle latency, node failure, bandwidth, etc. differently. > What happens when getting resource A takes 100 times longer than getting > resource B? (Their answer seems to be caching) No. Their answer would be that one uses a different schema. Caching is a natural consequence of any REST style architecture. > What happens when you > only ever access a resource once? (latency problem) That hit is with you no matter what, but different schema for the URI's take into account such issues as well as any ad hoc approach is likely to. >What happens when > you cache a resource and it changes out from under you? (coherency) A major feature of REST architecture is that by design caches are coherent. This is one of the main arguments for using REST instead of SOAP interfaces at the http level. >How > do lower level failures ask the upper application layers for advice on > recovery? Good question. I do not know. Clearly a "hinting' mechanism would be of real use. But again I consider this an important open question. Not merely one that is an issue with NetKernel either, but which applies to almost any multi-level architecture. > UDP hole punching is just my way of putting a concrete problem down to > highlight the issues. OK. > UDP hole punching has all of the features necessary to test what's going > on. Resources behind firewalls are harder to get to than local or > non-firewalled resources. Connections can suddenly block and need to be > renegotiated, or, worse, the connection can get dropped *and* the > resource then changes. Agreed. I believe that REST addresses the cache coherency issues associated with this sort of problem. I would need to check the correctness of this belief. BTW, I would love to see a few LPSG sessions (If LPSG still meets) devoted to a careful reading of Roy Fielding's thesis. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm > A low-level failure (dropped connection) may have multiple recovery > strategies: ignore (non-critical or latency critical), error correct > (let the high level application ride through the problem with coding, > etc.), retry (force the low-level to reconnect and retransmit), > alternative (find another resource at the application level or transport > level), die (no viable recovery). Right, which is why one has different schema for the resolution of the URIs for different levels. This is _not_ just http. > All resources are not the same and do not have the same characteristics. > Low-level sometimes *does* matter--generally when performance is on > the line. Totally agree. No one has said that "all resources are the same." What is being said is that "All resources have certain common abstract properties." This is a far cry form saying "All resources are the same." I can say "all physical objects have mass." I have not said "All physical objects have the same mass." Nor have I said "All physical objects are the same." > When performance doesn't matter, almost anything will work. I, however, > want something that will work even at the high performance end, or, at > least, give me the hooks to do what I need when performance matters. Agreed. I think that NetKernel is point toward a middle way that is going to be very important. No one is ever going to craft more than a very few applications in a truly performance optimized way to run on muli-cpu kernels. So some way must be found to map applications onto those chips. I think NetKernel/REST with load balancing is going to one of those ways. YMMV. So far though you have _not_ IMHO addressed what NetKernel is really about. You keep raising red herrings like the assertions about "all resources are not the same," which is an undeniable truism and also irrelevant since NetKernel makes no such assertion. > The trick is to not have to invest too much extra when things are simple > and yet still have the ability to handle the complex. Perhaps though I can also argue that if one can solve 80% of the problems with a simple solution then one must consider allowing some other mechanism to be used for the other 20% of the problems. The "trick" may well be in knowing which problems to solve and which to ignore. Good exchange :) BobLQ -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
