Issue 4180: set_directory effect unclear (ftamftp-ftf) Source: DSTC (Mr. Ted McFadden, mcfadden@dstc.edu.au) Nature: Uncategorized Issue Severity: Summary: The specification states that Directory::set_directory is used to allow a client to "update or populate the contents of a Directory object." so that it mirrors the true contents of a remote server. However, at any point in time after the call to set_directory, the Directory can get out of sync with the remote server it represents. Even after a call to list() is made, either the returned sequence or FileIterator can return stale results. What I'm suggesting that the sync point is an implementation detail. It may be appropriate for some implementations to sync on every call to Directory::list or FileIterator::next_n. If an implementation did nothing in response to set_directory could a client tell? If not, must a client call set_directory before it can call list or get_property_value("num_children")? I ask these questions because neither the Naming or Trader services, which have similar iterators, have any kind of set or refresh operation to sync with their datastore. I'm also a bit confused because in Chapter 4 Section 4.3.2, you do not have to call set_directory on the root directory returned from log_in(), but then you do on any subsequent directories. The name set_directory indicates a kind of change working directory operation as in an ftp or ftam client app but it doesn't seem to apply in this situation. Action Requested: If set_directory is required, spec must state when it needs to be called in Chapter 3. If its not required, remove it and state that it is up to the Directory implementation when it takes a "snapshot" of the remote server. Resolution: Removed the operation from the IDL. There is no concept of a “current directory”. Revised Text: The text that described the operation in the FileTransferSession section has been removed during the resolution of other issues. The chapter “Example Scenarios” has also been removed from the specification as it is no longer applicable. These changes removed all references to set_directory. Actions taken: January 30, 2001: received issue Discussion: End of Annotations:===== Date: Tue, 30 Jan 2001 22:13:43 +1000 From: Ted McFadden To: issues@omg.org, ftamftp-ftf@omg.org Cc: tmcf@ooc.com.au Subject: ftam/ftp issue: set_directory operation unclear Message-ID: <20010130221343.C16495@ooc.com.au> Reply-To: Ted McFadden Mail-Followup-To: issues@omg.org, ftamftp-ftf@omg.org Mime-Version: 1.0 Received: from errigal.ooc.com.au (IDENT:root@errigal.ooc.com.au [10.1.1.5]) by janus.ooc.com.au (8.9.3/8.9.3) with ESMTP id AAA08456 for ; Wed, 31 Jan 2001 00:54:18 +1000 Received: (from tmcf@localhost) by errigal.ooc.com.au (8.9.3/8.9.3) id AAA16823 for tmcf@ooc.com.au; Wed, 31 Jan 2001 00:54:18 +1000 Received: from errigal.ooc.com.au (IDENT:root@errigal.ooc.com.au [10.1.1.5]) by janus.ooc.com.au (8.9.3/8.9.3) with ESMTP id XAA08068 for ; Tue, 30 Jan 2001 23:35:55 +1000 Received: (from tmcf@localhost) by errigal.ooc.com.au (8.9.3/8.9.3) id XAA16696 for tmcf@ooc.com.au; Tue, 30 Jan 2001 23:35:55 +1000 Received: from errigal.ooc.com.au (IDENT:root@errigal.ooc.com.au [10.1.1.5]) by janus.ooc.com.au (8.9.3/8.9.3) with ESMTP id WAA07895 for ; Tue, 30 Jan 2001 22:13:43 +1000 Received: (from tmcf@localhost) by errigal.ooc.com.au (8.9.3/8.9.3) id WAA16600 for tmcf@ooc.com.au; Tue, 30 Jan 2001 22:13:43 +1000 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: p#Be9P=(!!Ga&!!%"De9 Maybe I'm misunderstanding the intent of set_directory but I'm not sure the method is necessary. ftp/ftam issue: set_directory effect unclear -------------------------------------- The specification states that Directory::set_directory is used to allow a client to "update or populate the contents of a Directory object." so that it mirrors the true contents of a remote server. However, at any point in time after the call to set_directory, the Directory can get out of sync with the remote server it represents. Even after a call to list() is made, either the returned sequence or FileIterator can return stale results. What I'm suggesting that the sync point is an implementation detail. It may be appropriate for some implementations to sync on every call to Directory::list or FileIterator::next_n. If an implementation did nothing in response to set_directory could a client tell? If not, must a client call set_directory before it can call list or get_property_value("num_children")? I ask these questions because neither the Naming or Trader services, which have similar iterators, have any kind of set or refresh operation to sync with their datastore. I'm also a bit confused because in Chapter 4 Section 4.3.2, you do not have to call set_directory on the root directory returned from log_in(), but then you do on any subsequent directories. The name set_directory indicates a kind of change working directory operation as in an ftp or ftam client app but it doesn't seem to apply in this situation. Action Requested: If set_directory is required, spec must state when it needs to be called in Chapter 3. If its not required, remove it and state that it is up to the Directory implementation when it takes a "snapshot" of the remote server. Cheers, Ted -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill 4169, QLD. Australia > #4180: It is probably safe to remove the > set_directory, and state that the directory "snapshot" > be taken as part of the list operation. > Just to clarify, depending on the implementation what the client would consider a snapshot can happen at any time and may not include the entire logical Directory. Our implementation would not necessarily guarantee a snapshot of an entire directory is taken when list or next_n is called. Cheers, Ted -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts http://www.ooc.com Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill 4169, QLD. Australia