Issue 4391: Directory::list and FileWrapper                                                                                                                                                                         (ftamftp-ftf)
Source: DSTC (Mr. Ted McFadden, mcfadden@dstc.edu.au)
Nature: Uncategorized Issue
Severity: 
Summary: The Directory::list & FileIterator operations return sequences of 
FileWrappers defined as:

             struct FileWrapper {
                    File the_file;
                    FileType file_type;
             };


This has the unforunate side effect of creating large numbers of
unnecessary File object references.

For example, to query a directory with 10,000 Files. The server must
return 10,000 separate usable file references. If I then want the
names of the files, that's 10,000 more calls to File::get_name().

Even if the server implementation is clever and is only generating
references for these files and not directly backing them with
servants, the server must maintain some context about them.

Considering a client will probably only transfer a minority of the
references it receives from list it would be advantageous to structure
the list operation to return the relative names of the entries to the
enclosing directory:

   struct DirEntry {
   wstring relative_name;
   FileType file_type;
   };

Then, the client has immediate access to what is arguably the most
frequently accessed File attribute (the name), and the File object can
then be gotten by adding a get_file operation on the Directory itself.

Further to making the list call more useful and not having to make
mutiple calls on each File object to query attributes, the list
signature could be:

          Directory::list(in CosPropertyService::PropertyNames listProps)

          struct DirEntry { 
             RelativeName name;
             CosPropertyService::Properties props;
             DirEntryType type;
          };

Now it is easy for a client, to obtain a directory listing with file
names, size, owner, etc... without forcing the server to create *any*
File references and eliminating any client calls to these references.

Only if the client wants to transfer or delete a file will it have to
ask for a reference.

Resolution: see above
Revised Text: Section 3.1.4 FileSystemEntry, 3.1.5 Directory Interface, 3.1.6 DirEntryIterator Interface,
3.1.7 File Interface
Actions taken:
June 25, 2001: received issue
Discussion: 
Resolution
IDL changes similar to those described in the summary. The Directory::list operation
returns an iterator for DirEntry structs which contain the simple name and requested
properties of FileSystemEntries. The Directory interface has a get_file operation that
takes a multi-component path name argument relative to that Directory. This is similar to
a CosNaming::Name.
End of Annotations:=====
Date: Mon, 25 Jun 2001 16:31:20 +1000
From: Ted McFadden <ted.mcfadden@iona.com>
To: issues@omg.org
Subject: ftam/ftp ftf issue: Directory::list and FileWrapper
Message-ID: <20010625163120.J13898@iona.com>
Mail-Followup-To: issues@omg.org
Mime-Version: 1.0
X-Mailer: Mutt 1.0i
Content-Type: text/plain; charset=us-ascii
X-UIDL: -d<e9m2""!fgBe9<~O!!

ftam-ftp FTF issue: Directory::list and FileWrapper
-----------------------------------------------------------------------

The Directory::list & FileIterator operations return sequences of 
FileWrappers defined as:

             struct FileWrapper {
                    File the_file;
                    FileType file_type;
             };


This has the unforunate side effect of creating large numbers of
unnecessary File object references.

For example, to query a directory with 10,000 Files. The server must
return 10,000 separate usable file references. If I then want the
names of the files, that's 10,000 more calls to File::get_name().

Even if the server implementation is clever and is only generating
references for these files and not directly backing them with
servants, the server must maintain some context about them.

Considering a client will probably only transfer a minority of the
references it receives from list it would be advantageous to structure
the list operation to return the relative names of the entries to the
enclosing directory:

   struct DirEntry {
   wstring relative_name;
   FileType file_type;
   };

Then, the client has immediate access to what is arguably the most
frequently accessed File attribute (the name), and the File object can
then be gotten by adding a get_file operation on the Directory itself.

Further to making the list call more useful and not having to make
mutiple calls on each File object to query attributes, the list
signature could be:

          Directory::list(in CosPropertyService::PropertyNames
          listProps)

          struct DirEntry { 
             RelativeName name;
             CosPropertyService::Properties props;
             DirEntryType type;
          };

Now it is easy for a client, to obtain a directory listing with file
names, size, owner, etc... without forcing the server to create *any*
File references and eliminating any client calls to these references.

Only if the client wants to transfer or delete a file will it have to
ask for a reference.

-- 
Ted McFadden                               ted.mcfadden@iona.com
IONA Total Business Integration (TM)
Suite 4, 8 Martha St.			   +61-7-3324-9633
Camp Hill, Brisbane, 4169, QLD. Australia