GFS-WG #1 - Resource Namespace Service

Tuesday, March 15, 2005
5pm to 6:30pm

31 participants

Note taker: Osamu Tatebe (AIST)

Agenda
------
 - Introduction               (by Osamu Tatebe, AIST)
 - Resource Namespace Service (by Manuel Pereira, IBM)
 - Status discussion about RNS

Meeting
-------
 - Introduction (by Osamu Tatebe)
   * VFDS -> RNS + file system profile
   * new naming WG

 Q: Why general service is necessary?
 A: We would like to create fundamental core service of naming for
    wide adaptibility from other services and wide use.
    VFDS functionality can be realized by defining a profile for
    virtual filesystem directory service.

 - Resource Namespace Service (by Manuel Pereira)

  * RNS 
    - A WSRF compliant Web Service that provides namespace services
      for any addressable entity
    - Easily accessible, hierarchical managed, name
    - document style messaging

  * Operation
    - very simple - create, delete, list, lookup, update
    - extensibility - deleteProperty, insertProperty, listProperties,
                      updateProperty

  * Components
    - Virtual Directories
    - Junctions (Virtualized Referenes, Endpoint References,
                 Referrals, Aliass)

  * Document Style Messaging
    - Beyond Traditional RPC
    - WSRF compliant
    - RNS IteratorContext
    - RNS Entry

 Q: Is it better to specify index for list operation by client rather
    than keeping it at the server side?
 A: There is a problem when entries of list are updated between two
    list opearations.  In this case, offset specified by a client may
    be not correct.

 Q: Is Alias a hard link?  Is reference count for a aliase? 
 A: Yes.  When a target entry (an owner of the property) of an alias
    is deleted, one of the aliases will become the owner of the
    property.

 Q: Can an alias point to another virtual directory. - Yes.
 Q: Is an alias possible to point to another service?  - No, it is referral.

 Q: If there are multiple aliases targetting to a specific virtual
    directory, how do you manage the DirectoryPath?
 A: Even alias entry has a PID (OID for the parent directory entry).
    It is different from a hardlink.

 Q: When there is a referral during directory path resolution, what happen?
 A: There are two ways; service referrals and delegate resolution.
    (See the section "Federation of Resource Namespace Services".)

 Q: How does client keep an appropreate server?
 A: The RNS specification does not specify implementation details nor
    does it describe client/application capabilities.  The
    specification only specifies a standard for the service and
    thereby describes the service's interface.  Implementation
    optimizations are certainly possible and are the responsibility of
    the client/application implementer.  A client may maintain a cache
    of path names, top level resolution service addresses, most
    appropriate RNS service address to exchange messages with, etc.

 Q: Does RNS support notification when something is changed to
    maintain consistency?
 A: No, not yet.  We are now considering.

 Q: How about the uniquness in namespace?
 A: All of entries in a directory should have an unique name.

 Q: How to specify unique abstract name?
 D: there is big discussion about abstract name.  The followings are
    just notes.
    o This is a issue of WS-naming not RNS.
    o how to guarantee the uniqueness (with extremely high probability)
    o GUID is not ensure the uniqueness
    o It is an extremely challenging issue to guarantee the uniquness.
    o MAC address is not unique.
    o There are several projects to see this issue. randum number
      generator, ...

 * RNS recent revision

 C: Many people use 'Logical Name' as a human readable name.
 C: 'Abstract name' is a subset of 'Logical Name'

 Q: How to differenciate a file and a collection?
 A: This may be solved by adding file system profile.

 Q: A client might want to know more information than Entry
    properties.
 A: It is not efficient to resolve all entries in a directory during
    the list operation.  This also may be solved by file system
    profile.

  - OID clarification

 D: OID is cachable, but it is not reliable.  Also, the semantics
    depends on implementation.  Is it better that OID is not exposed
    in the spec?

    There is a problem when OID is re-used.

    It is ok just to describe OID is not reliable in the spec.

 - Status discussion about RNS
   - Discussion points;
     o Is RNS specification general enough?
     o How much refinement may be needed?

 C: It is better to finalize the document now and submit it.  (And
    iterate the revision)
 C: RNS spec is almost complete.    

Q: Question
A: Answer
D: Discussion
C: Comment