Hello All, I was hoping to provide a quick response to Andrew's comments today, however due to unexpected personal reasons I was unable to. I will not be available until Monday next week, at which time I will provide a brief response to each of the points listed. Best regards, Manuel Pereira =============================== IBM Almaden Research Center 1-408-927-1935 [T/L 457] mpereira@us.ibm.com owner-ogsa-wg@ggf.org wrote on 07/20/2005 11:55:00 AM:
All, Here are some of my comments on the RNS document. I jammed my finger yesterday in basketball, so typing is painful. Therefore, I?m limiting my comments to the most significant. Thank you to the RNS team for all of their work.
Andrew
High level comments:
1) The basic directory function is to provide a mapping handle f(?string?), i.e., to map strings to some form of handle.
Thus, in section 1.1. Why do we need four different types of junctions? Should we not have one type of junction: mainly to an EPR. Thus a directory would map a string to an EPR. EPR f(?string?); Instead there are four ?types? of junctions: EPR?s Virtualized reference ? either contains an EPR or a URL that points to some other service Referrals ? point to another RNS service. Q: could this not be modeled as an EPR? Alias ? points to another ?entry? within the ?same? RNS service. This seems to imply a container like model ? more on this later.
I suggest that we need only ONE type of junction ? an EPR. That will simplify client coding ? and the model significantly.
2) Implied model ? Repositories There is a notion in the spec of ?same service instance? that in conversations has also been called a ?repository?. The basic idea is that an RNS service may ?contain? a set of directories ? and that the service has a root. Thus junction types distinguish, for example, between internal and external things that they point to. Thus an RNS service is a rooted tree ? that may point at the leaves to other rooted trees. So, first of all ? it is implied. If we?re going to have that model it should be right up front and discussed. What is a repository? What are it?s special port types if any, etc. Second, I think that it is not the right way to think about the problem. Directories should be the resources ? not collections of directories. If a particular implementation chooses to multiplex a large number of logically independent directories in a single container ? great ? we will certainly do that too. The issue is what is the model. I feel fairly strongly about this.
Links ?into? other RNS servers:1.1.2.4 ?Alias Junction? is restricted to pointing to entries in the same repository. I think they should be able to point to anything ? including directories in ?other? repositories. It has been claimed that using the EPR of the ?repository? and a path you can get that effect. However, what if the path changes in the other container? My link would break ? even if the directory itself still exists.
3) Full path names In ANY directory system lookup really takes two parameters ? a ?root? at which to start, and a path. Often the ?root? is implied, or is at some well-known location. RNS ? as written, implies that all lookups are based on full paths with an implied, unspecified root. Assuming that full paths are to be used on all lookups, the potential for both hot spots AND single point of failure are clear. In conversation with Manual he mentioned that his clients cache intermediate parts of the tree in the sense that ?/foo/bar/d1? as a prefix leads to a particular RNS service, and then use that info to not always traverse the tree. Besides the obvious implementation challenges of cache consistency when the tree is changing (a problem we certainly had/have in Legion) there is the modeling issue. If we expect clients to do that ? then perhaps the architecture/specification should accommodate that and say that all lookups are relative path lookups with respect to some ?root?. The root could be a true ?root?, or interior node in a tree, which is itself a ?root? of the subtree it defines.
4) Resolve and file system profile. We discussed these on the last ogsa call, my understanding is that they are going out.
5) Iterators. OGSA-Data-WG has discussed iterators in a more general way, e.g., on data base query results etc., I think that whatever is done in RNS should be consistent with whatever is done in OGSA-Data (note ? consistency can happen either way).
Medium level comments:
S 1.1 ?In all cases, junctions are capable of maintaining a list of references (EPRs/URLs) per entry, that is a single junction my render several available EPRs, each of which represent replicas, copies of the same resource, or operationally identical services. ?
Why? Are you saying that replication issues and semantics should be dealt with in the directory structure? Or are you saying that directories are not ?sets? in the sense of only one entry ? but rather ?multi-sets? in the sense that one string can map to multiple things. If the later ? what are the implied semantics. I think it may be safer to keep them as sets.