Null Arguments Are Okay Attributes Are Single Valued Contexts Are Handled by a Separate Set of Methods

Given that attributes can be omitted, its not very surprising that attributes are treated differently from paths and names in a methods such as: public Remote lookupPath path, String name, AttributeSet attributes throws RemoteException, NamingException; However, the fact that server names are treated differently from context names might seem a bit surprising. When I defined paths, I said: If we form a path from the strings usr , bin , and games which we denote by usrbingames we make the following assertions: there is a context named usr ; if we list the subcontexts of usr , we will find a subcontext named bin ; if we list the subcontexts of bin , we will find a context named games . The meaning of the separation of path from name is that specifying the path usrbingames, which specifies a subcontext of the base context, is different than specifying the name games and the path usrbin, which specifies a server bound locally into the context specified by usrbin. Its worth repeating this in a slightly different way: the namespace for subcontexts is different than the namespace for locally bound servers. That means the following four queries, written in pseudocode, can all return different results: lookupusrbingames, tank, null Returns all servers named tank in the context specified by the path usrbingames. lookupusrbingamestank, null, null Returns all servers from the context specified by the path usrbingamestank. The server is guaranteed to match the name and attribute properties. However, since theyre null , any server from the context will do. lookupSubContextusrbingamestank, null Returns all subcontexts of the context specified by the path usrgamesbintank. lookupSubContextusrbingames, tank Returns the subcontext named tank of the context specified by usrbingames. This design decision is rather arbitrary. I feel the last two points are really separate cases, and the first two just fell out of how I think about things. Other design decisions are quite possible and indeed, may be the usual case here.

15.4.3 Null Arguments Are Okay

An important feature of the query functionality is that null arguments are perfectly okay. If a client doesnt care about any attributes, it can pass in a null value for the attributes argument, or call a variant of the method that doesnt even have an attributes argument. Similarly, if any server will do, the name can be null. Its perfectly reasonable for someone to say, I want a printer that supports color PDF files. The naming service equivalent of this is, Go to the subcontext named Printers and query solely on attribute values.

15.4.4 Attributes Are Single Valued

For ease of implementation, and because its not entirely clear what multiple valued attributes mean when querying, attributes are single valued in the current implementation. This works quite well in our use case involving the bank example but isnt quite flexible enough to make the printer example feel natural. For example, consider document-types. Our printer example currently has three: PDF, PostScript, and PCL. We have two options: • We can encode this as delimited strings. For example, we can say that the document type attribute takes one of the following values: pdf, postscript, pcl, pdf, postscript, postscript, pcl, pdf, pcl, or pdf, postscript, pcl. • Alternatively, we can encode this as boolean-valued attributes: handles pdf, handles postscript, and handles pcl. This might be the first requirements-level decision reversed in Version 2.0.

15.4.5 Contexts Are Handled by a Separate Set of Methods

Recall that contexts can be bound into other contexts without being subcontexts. In order to fully support this, we need to have a separate set of context-specific methods. Calling: public void bindPath path, String name, AttributeSet attributes, Remote server and passing in an instance of Context is semantically distinct from calling: public void bindSubContextPath path, String name, Context context throws RemoteException, NamingException; and passing in the same arguments. Note that in order to pass in the same arguments, the attribute set has to be null in the first call. This extra bit of flexibility is rarely used, but is traditional. [ 3] [ 3] Traditional in distributed computing often means, as it does here, The people who designed CORBA did it this way, and I cant think of a good reason to change it.

15.4.6 Contexts, When Bound as Contexts, Have No Attributes