Fault Tolerant CORBA® Avatar
  1. OMG Specification

Fault Tolerant CORBA® — Closed Issues

  • Acronym: FT
  • Issues Count: 46
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
FTAM-37 Active vs. passive connect for file transfer (Firewalls....) FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-36 Use of AccessLevel Struct FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-35 The Directory::list operation is underspecified FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-34 set_directory effect unclear FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-33 Remove restrictions FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-32 Accessing Server-side File Systems: FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-31 FTAM/FTP Issue delete FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-30 ftam-ftp FTF issue: login operation parameters FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-29 ftam-ftp FTF issue: Exception definitions FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-28 ftam-ftp FTF issue: file time attributes are strings FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-27 tam-ftp FTF issue: File::create_file does not create a file FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-26 ftam-ftp FTF issue: Missing transfer operations FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-25 ftam-ftp FTF issue: FileSystemID FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-24 Why does File derive from PropertySetDef? FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-23 Directory::list and FileWrapper FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-22 64 bit file systems FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-21 ftam/ftp issue: lifecycle of FileTransferSession, Directory, and File FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-17 ftam/ftp issue: Setting up file transfers and transfer protocols FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-19 listening socket determination of source / destination File FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-18 Cannot transfer files if Files have same associated_session FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-20 Exposure of Virtual File System implementation details FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-16 ftam/ftp issue: binary vs text file transfer FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-15 Use of Istring in IDL FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-14 How does transfer operation determine FileTransferSession object identity FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-13 FileIterator interface operations not defined in spec FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-11 FileTransferSesion:insert method signature mismatch FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-10 Transfer operation protocol negotiation unspecified FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-12 Use of Directory in transfer/insert/append/delete operations FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-9 Architecture issue FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-8 'delete' operation is C++ keyword FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-7 CommandNotImplementedException FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-6 The NativeFileSystemType enumeration has to be changed FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-5 ProtocolSupport struct FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-2 We should clarify the roles of sender and receiver FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-1 beef up the discussion of how the Property Service is to be used FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-4 Type name & parameter name should differ by more than just case FTAM 1.0b1 FTAM 1.0 Resolved closed
FTAM-3 We need to discuss the protocols supported FTAM 1.0b1 FTAM 1.0 Resolved closed
FT-7 Encoding of Service Contexts in Fault Tolerant CORBA specification missing FT 1.0b1 FT 1.0 Resolved closed
FT-6 Propose Remove use of Filter FT 1.0b1 FT 1.0 Resolved closed
FT-5 Issue with 'factory' FT 1.0b1 FT 1.0 Resolved closed
FT-4 define the State as typedef any State FT 1.0b1 FT 1.0 Resolved closed
FT-3 following question regarding modifications to CORBA core FT 1.0b1 FT 1.0 Resolved closed
FT-11 On page 27-9 of the FT CORBA spec, under "Application-Controlled Membership FT 1.0b1 FT 1.0 Resolved closed
FT-10 term "method" used wrongly FT 1.0b1 FT 1.0 Resolved closed
FT-9 Harmful deprecation of LOCATE_FORWARD_PERM for Faut Tolerant CORBA FT 1.0b1 FT 1.0 Resolved closed
FT-8 typedef issue FT 1.0b1 FT 1.0 Resolved closed

Issues Descriptions

Active vs. passive connect for file transfer (Firewalls....)

  • Key: FTAM-37
  • Legacy Issue Number: 4229
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    n Section 4.5.2, the specification provides a sample skeleton of the
    transfer operation where the protocol information available for the
    destination FileTransferSession is "TCP/IP" with a listening address
    of "255.255.25.1:8001"

    The specification is requiring that the receiver of a file must allow
    incoming connections.

    Forcing the sender to always connect() and the receiver to always
    listen() will cause unnecessary trouble with firewalls.

    Since any file transfer could also be accomplished by allowing the
    sender to listen and the receiver to make the active connection the
    protocol specification should allow for active, passive (or either)
    connections.

    (A similar issue was raised against the A/V streams spec: issue #2053)

  • Reported: FTAM 1.0b1 — Wed, 21 Mar 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:33 GMT

Use of AccessLevel Struct

  • Key: FTAM-36
  • Legacy Issue Number: 4390
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The access_rights property is defined as an AccessLevel struct. A
    client is able to query this property from a File or
    Directory. AccessLevel is defined as:

    struct AccessLevel

    { boolean read; boolean insert; boolean replace; boolean extend; boolean erase; boolean read_attr; boolean change_attr; boolean delete; }

    ;

    and represents the permissions granted to a user. In practice it is
    not always possible for a service implementation to know the values of
    all of these attributes. Unfortunately there is no way for a service
    to report if any of these values cannot be determined.

    The ftam spec should provide some means to determine the validity of
    the boolean values in this struct, or at the very least specify the
    default values for unknown members.

  • Reported: FTAM 1.0b1 — Mon, 25 Jun 2001 04:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    Remove the struct from the IDL.

  • Updated: Sat, 7 Mar 2015 04:33 GMT

The Directory::list operation is underspecified

  • Key: FTAM-35
  • Legacy Issue Number: 4181
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The parameters of the Directory::list method are underspecified which
    makes interoperability a problem. (We just went through this with the
    NamingContext::list operation in the Naming RTF/FTF.)

    A more rigorous definition of list (borrowed from Section 3.3.8 of
    the INS spec formal/00-08-07) is:

    void list (in unsigned long how_many,
    out FileList fl,
    out FileIterator fi);

    list returns the Files contained in a Directory in the parameter fl.
    The fl parameter is a sequence where each element is a FileWrapper.

    The how_many parameter determines the maximum number of Files to return
    in the parameter fl, with any remaining bindings to be accessed
    through the returned FileIterator fi.

    • A non-zero value of how_many guarantees that fl contains at most
      how_many elements. The implementation is free to return fewer than the
      number of Files requested by how_many. However, for a non-zero
      value of how_many, it may not return a fl sequence with zero elements
      unless the Directory contains no Files.
    • If how_many is set to zero, the client is requesting to use only the
      FileIterator fi to access the Files and list returns a zero
      length sequence in fl.
    • The parameter fi returns a reference to an iterator object.
    • If the fi parameter returns a non-nil reference, this indicates that
      the call to list may not have returned all of the bindings in the
      Directory and that the remaining Files (if any) must be retrieved
      using the iterator. This applies for all values of how_many.
    • If the fi parameter returns a nil reference, this indicates that the
      fl parameter contains all of the Files in the Directory. This applies
      for all values of how_many.

    Action Requested: Make description of list operation cover these
    interoperability points.

  • Reported: FTAM 1.0b1 — Tue, 30 Jan 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:32 GMT

set_directory effect unclear

  • Key: FTAM-34
  • Legacy Issue Number: 4180
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • 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.

  • Reported: FTAM 1.0b1 — Tue, 30 Jan 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    Removed the operation from the IDL. There is no concept of a “current directory”.

  • Updated: Sat, 7 Mar 2015 04:32 GMT

Remove restrictions

  • Key: FTAM-33
  • Legacy Issue Number: 4056
  • Status: closed  
  • Source: Siemens AG ( Alan Burger)
  • Summary:

    10. Currently, it is mandatory that the source and target File Transfer Sessions are using the same protocol, e.g., both FTAM or both FTP. It would be nice if this restriction were removed. If an implementation of the Gateway supports both protocols, the gateway could use one protocol to copy the file from the source file system to local storage, and then use the other protocol to copy it from local storage to the target file system.

  • Reported: FTAM 1.0b1 — Wed, 23 May 2001 04:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    rejected

  • Updated: Sat, 7 Mar 2015 04:32 GMT

Accessing Server-side File Systems:

  • Key: FTAM-32
  • Legacy Issue Number: 3821
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There is no operation in the IDL to allow for directly accessing a file’s contents. However, this scenario has been considered. In order for a CORBA application to access the contents of the files on a server-side file system, it would be necessary for that application to provide an object implementing the FileTransferSession interface. Only the FileTransferSession::transfer (in File src, in File dest) operation and the FileTransferSession::protocols_supported attribute would have to be fully implemented. The procedure for transferring the contents of a file would be as follows;
    The reduced FileTransferSession would be instantiated.
    A File object would be created, setting the associated_session attribute to point to the reduced FileTransferSession object. The name, complete_file_name and parent attributes can be set to arbitrary values.
    The FileTransferSession::transfer() operation would be called on the remote FileTransferSession, passing in the remote File as the src parameter, and the locally created File as the dest parameter.
    The reduced FileTransferSession object would accept transport connections on the address’s specified by the FileTransferSession::protocols_supported attribute. When the connections have been set up, the remote FileTransferSession will call the transfer() operation on the reduced FileTransferSession, and transfer will commence.
    The reduced FileTransferSession object can then read the contents of the file from the transport connection.
    Data may be written to a remote file in a similar fashion, however the reduced FileTransferSession will have to be able to set up transport connections. The append() operation may also be implemented in the same way, if so desired.

  • Reported: FTAM 1.0b1 — Mon, 11 Sep 2000 04:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:28 GMT

FTAM/FTP Issue delete

  • Key: FTAM-31
  • Legacy Issue Number: 3820
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The FileTransferSession::delete (in File file) operation will have to be changed to accommodate the C++ keyword “delete”. This should be changed to FileTransferSession::delete_file (in File trash). This is in keeping with the style of other operations, e.g. get_file, create_file, etc. The File parameter name should be changed in accordance with an earlier comment.

  • Reported: FTAM 1.0b1 — Mon, 11 Sep 2000 04:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Sat, 7 Mar 2015 04:28 GMT

ftam-ftp FTF issue: login operation parameters

  • Key: FTAM-30
  • Legacy Issue Number: 4428
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The login operation allows for specification of a user, password, and
    account. The spec notes that account is optional. There are any number
    of other login properties that affect client access to a file system
    but no way to specify them.

    Consider adding a property sequence to the login argument so that
    optional properties can be specified. The `optional' account argument
    can then be removed.

    chang signature from:

    FileSession login(in string user,
    in string password,
    in string account,
    out Directory dir);

    to:

    FileSession login(in string user,
    in string password,
    in CosPropertyService::Properties props,
    out Directory dir);

  • Reported: FTAM 1.0b1 — Wed, 25 Jul 2001 04:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    Change IDL for login as suggested.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

ftam-ftp FTF issue: Exception definitions

  • Key: FTAM-29
  • Legacy Issue Number: 4427
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The spec defines six exceptions that carry no information other than a
    text string to describe the error. This leads to cumbersome coding on
    the client side.

    Consider a single exception with a reason code. This conveys the same
    information without requiring 5 or 6 catch blocks in some languages.

  • Reported: FTAM 1.0b1 — Wed, 25 Jul 2001 04:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

ftam-ftp FTF issue: file time attributes are strings

  • Key: FTAM-28
  • Legacy Issue Number: 4426
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The File attributes for creation_time and mod_time are defined as strings.
    Without better specification, this is not useful. The types of these
    attributes should be TimeBase::UtcT.

  • Reported: FTAM 1.0b1 — Wed, 25 Jul 2001 04:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    The property types have been changed to TimeBase::UtcT.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

tam-ftp FTF issue: File::create_file does not create a file

  • Key: FTAM-27
  • Legacy Issue Number: 4425
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The operation create_file doesn't create a file, unlike
    create_directory which does create a directory. create_file creates a
    target proxy for a file transfer.

    Consider removing create_file and adding a boolean flag to the very
    similar get_file operation to indicate whether underlying file
    existence is required.

  • Reported: FTAM 1.0b1 — Wed, 25 Jul 2001 04:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

ftam-ftp FTF issue: Missing transfer operations

  • Key: FTAM-26
  • Legacy Issue Number: 4424
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    With FTP and FTAM it is possible to monitor the progress of data transfers
    and to abort them. The current spec provides no way to terminate or determine
    the progress of a transfer. Consider adding some way to obtain the status /
    progress of a file transfer and to abort an in progress transfer.

  • Reported: FTAM 1.0b1 — Wed, 25 Jul 2001 04:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

ftam-ftp FTF issue: FileSystemID

  • Key: FTAM-25
  • Legacy Issue Number: 4423
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    It would be very useful for generic clients if the FileSystem would
    identify itself somehow with a get_system_id() that returned an id
    string. This would be similar to the string that is returned to
    identify an FTP server.

    There is no need for this string to be globally unique.

  • Reported: FTAM 1.0b1 — Wed, 25 Jul 2001 04:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Why does File derive from PropertySetDef?

  • Key: FTAM-24
  • Legacy Issue Number: 4409
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The spec states the File interface derives from
    CosProperty::PropertySetDef and lists the properties that can be
    associated with a file: is_directory, creator, size, mod_time,
    create_time, access_rights, name, complete_file_name and num_children.

    Under what circumstances could a client validly change the property
    mode of one of these? A client could certainly change the values of
    some of these but not the modes of the properties themselves.

    Unless an example can be provided that shows a need to modify the
    property mode, File should derive from PropertySet not PropertySetDef.

  • Reported: FTAM 1.0b1 — Thu, 12 Jul 2001 04:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    Change FileSystemEntry Interface to derive from PropertySet.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Directory::list and FileWrapper

  • Key: FTAM-23
  • Legacy Issue Number: 4391
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • 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.

  • Reported: FTAM 1.0b1 — Mon, 25 Jun 2001 04:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

64 bit file systems

  • Key: FTAM-22
  • Legacy Issue Number: 4389
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    Given the appearance of 64 bit file systems, consider changing the
    types used to represent file length and insertion offsets to unsigned
    long long so this specification can be used on large files.

  • Reported: FTAM 1.0b1 — Mon, 25 Jun 2001 04:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

ftam/ftp issue: lifecycle of FileTransferSession, Directory, and File

  • Key: FTAM-21
  • Legacy Issue Number: 4272
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    Once a FileTransferSession object is created on behalf of a client a
    large number of Directory and File objects can be created by calls to
    list and get_file. The specification does not address reclaiming
    server side resources when these objects are no longer required by the
    client.

    Once FileTransferSession::logout is called it can be inferred that all
    of the associated Directory and File objects should no longer be valid
    and can be reaped. The specification should state that they must no
    longer be valid, as you should not have access to a file or directory
    after you have logged out.

    If after using a number of file and directories a client has no
    further use for them, there should be a way for the client to inform
    the server. This requires a destroy() method on the File interface.

    Also, a robust virtual file system implementation must be allowed to
    reap FileTransferSession, Directory, and File objects at any time in
    order to reclaim resources from ill-behaved clients that acquire but
    do not release objects. The spec should mention that all clients, but
    particularly those that don't actively use File and Directory
    references for long periods, can expect OBJECT_NOT_EXIST exceptions.

  • Reported: FTAM 1.0b1 — Tue, 20 Feb 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

ftam/ftp issue: Setting up file transfers and transfer protocols

  • Key: FTAM-17
  • Legacy Issue Number: 4209
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    ftam/ftp issue: Setting up file transfers and transfer protocols
    ----------------------------------------------------------------

    In addition to the previous issues 4177, 4183 I've raised about file
    transfer and protocols I would like to recommend that a somewhat more
    complete approach be taken to managing the transfer operations
    (transfer, append, and insert).

    The current approach doesn't allow the virtual file systems to perform
    any kind of real protocol negotiation, resource/socket init, set-up
    acknowledge, or resource release.

    For instance, when speaking "TCP" as illustrated in Chapter 4, the
    port numbers are fixed by the supported_protocols attributes. A file
    system cannot change the port it would like to use on a per transfer
    request basis. This can be restrictive to allowing multiple transfers
    to happen in parallel or determining what file's data just came in on
    a socket.

    I am suggesting that an approach similar to the one used in the
    Audio/Video Stream specification be used. In this case an endpoint
    object would be established to represent each end of the file
    transfer. There is the opportunity for simple negotiation, such as
    picking protocols and port numbers.

    The IDL in the A/V Stream spec is far too heavy-weight for ftam/ftp
    but the concepts used for connection set-up and management are
    relevant. Just using a few of the A/V flow/end-point operations like
    set_peer, go_to_listen, and connect_to_peer would be sufficient.

    At OOC, we have begun experimenting with IDL that supports the notion
    of transfer `endpoints.' A different type of endpoint is created for
    each type of protocol, so matched protocol (such as TCP) endpoints
    talk to each other. And a CORBA endpoint is defined so two file
    systems can always transfer if they share no other common protocols.

  • Reported: FTAM 1.0b1 — Tue, 20 Feb 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

listening socket determination of source / destination File

  • Key: FTAM-19
  • Legacy Issue Number: 4228
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    In general (exception noted below) it is not possible for a receiving
    FileTransferSession to know what is the destination File for the data
    coming in over a socket. The receiver is never made aware of the
    sender's connection host and port, so it cannot distinguish multiple
    connections to the listening socket.

    The exception is that the transfer mechanism described in Chapter 4
    will work reliably as long as the following limitations apply:

    1. A FileTransferSession is involved in only one file transfer at a
    time so there is no ambiguity as to the data source and destination.

    AND

    2. A server process implementation makes each FileTransferSession
    listen on a different port or allow only one FileTransferSession to
    take part in a transfer at a time. This guarantees there is no
    ambiguity as to which FileTransferSession is involved in a file
    transfer.

    These are rather severe restrictions. Simultaneous transfers and reuse
    of server sockets can be accomplished if the transfer negotiation is
    augmented to exchange details such as host and port (somewhat like the
    ftp PORT command does to establish a data connection.) Such an approach
    is outlined in issue 4209.

  • Reported: FTAM 1.0b1 — Wed, 21 Mar 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    The resolution for issues 4177, 4209, and 4227 applies to this issue.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Cannot transfer files if Files have same associated_session

  • Key: FTAM-18
  • Legacy Issue Number: 4227
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    This issue concerns the operation:
    FileTransferSession::transfer(in File src, in File dest)

    and the associated operations append and insert.

    As described in section 4.5.2, in the transfer implementation, the
    FileTransferSession must first determine whether it is associated with
    the src or dest File in order to set up an active or passive
    connection.

    If it is the source, it sets up an active connection and then calls
    `transfer' again on the destination File's associated_session.
    Unfortunately, when both the src and dest files have the same_session,
    a FileTransferSession will always consider itself the source and
    unwanted recursion will result.

    The spec could say its forbidden to transfer files associated with the
    same FileTransferSession but this is extreme.

    It is also problematic to guarantee an implementation can detect this
    situation, as the FileTransferSession interface has no identity
    operations and a false return from is_equivalent is inconclusive. (The
    is_equivalent problem is also raised in Issue 4183).

    As with issue 4183, this issue could be resolved by not using the same
    transfer method to both initiate sending and receiving of data.

  • Reported: FTAM 1.0b1 — Wed, 21 Mar 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    The resolution for issues 4177, and 4209 resolves this issue.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Exposure of Virtual File System implementation details

  • Key: FTAM-20
  • Legacy Issue Number: 4230
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The FTAM RFP suggested implementations take a CORBA-centric approach
    and hide FTAM and FTP specific details.

    The VirtualFileSystem interface has an attribute file_system_type that
    can be: FTAM, FTP, or _NATIVE. There is also a supported_content_types
    attribute that returns a list of FTAM file type identifiers.

    This seems to be exposing implementation detail a client cannot
    directly use. If a client cannot make use of these they should be
    removed from the IDL.

  • Reported: FTAM 1.0b1 — Wed, 21 Mar 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

ftam/ftp issue: binary vs text file transfer

  • Key: FTAM-16
  • Legacy Issue Number: 4208
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    ftam/ftp issue: binary vs text file transfer
    --------------------------------------------

    Both FTP and FTAM make distinctions between text and binary files and
    use <CR><LF> newline encoding for text file transfer. FTAM has
    provision for identifying text or binary files by the FTAM type
    (FTAM1,FTAM2...) whereas FTP requires the client and server to
    somehow ascertain the file type before transfering as either text or
    binary.

    It also appears that depending on the real filestore implementation,
    an FTAM responder may not always be able to authoritatively determine
    a file's type unless it has been explicitly set by a user.

    Having said that, does the ftam/ftp idl need to allow for text/binary
    transfer in the transfer, append, and insert operations? Or for the
    purposes of this specification are all transfers to be considered
    binary?

    Requested Action: Some words in the specification about text vs.
    binary files.

  • Reported: FTAM 1.0b1 — Tue, 20 Feb 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    Treat all file transfers as binary.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Use of Istring in IDL

  • Key: FTAM-15
  • Legacy Issue Number: 4184
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The CosFileTransfer module typedef's string to Istring. This was used
    in the NamingService as a placeholder for an internationalized string
    type. We would have removed it in the INS FTF if we could have. .

    Since CosFileTransfer is new the opportunity should be taken to remove
    IDL constructs that are no longer useful.

  • Reported: FTAM 1.0b1 — Tue, 30 Jan 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    All string references in the IDL have been changed to wstring.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

How does transfer operation determine FileTransferSession object identity

  • Key: FTAM-14
  • Legacy Issue Number: 4183
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    From the description in Chapter 3, it is not clear how the
    FileTransferSession::transfer method is actually accomplished.

    Chapter 4 Section 4.5.1 describes the FileTransferSession examining
    the File reference's attributes to determine whether it is to initiate
    the transfer or receive the file. The initiator
    FileTransferSession::transfer implementation must then call transfer
    again on the target FileTransferSession.

    How, in a portable fashion, is a FileTransferSession to determine if
    it is the same FileTransferSession referred to in the src or dest File
    associated_session attribute?

    1. _is_equivalent cannot be used to compare FileTransferSession or other object
    references as a false return is inconclusive.
    2. There are no object identity operations defined on the
    FileTransferSession interface.
    3. None of the other File attributes denote unique identity (name,complete_name,
    as the src and destination file names can be identical.)

    Requested Action: Clarify how the File's attributes allow a FileTransferSession
    implementation to determine File ownership.

  • Reported: FTAM 1.0b1 — Tue, 30 Jan 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

FileIterator interface operations not defined in spec

  • Key: FTAM-13
  • Legacy Issue Number: 4182
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The FileIterator interface operations are not described in the spec.

    Action Requested: Insert text similar to Naming Service BindingIterator
    description.

  • Reported: FTAM 1.0b1 — Tue, 30 Jan 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    The DirEnryIterator is now defined in the specification.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

FileTransferSesion:insert method signature mismatch

  • Key: FTAM-11
  • Legacy Issue Number: 4178
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The `offset' parameter of the insert method is of type long but
    in the Section 3.3 File properties table on page 3-7 the file size
    property is unsigned long. The operation insert should work at
    any offset up to file size, so the types should be the same.

    Action Requested: The `offset' parameter and the file size attribute
    should be of the same type.

  • Reported: FTAM 1.0b1 — Tue, 30 Jan 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Transfer operation protocol negotiation unspecified

  • Key: FTAM-10
  • Legacy Issue Number: 4177
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    In Section 3.2 File Transfer Session, the transfer operation is
    described requires the source FileTransferSession and Target
    FileTransferSession to negotiate the transfer protocol by inspecting
    each other's protocols_supported attribute.

    This is problematic if either FileTransferSession supports more than
    one protocol as the protocol negotiation is not specified.

    For example take two FileTransferSessions that list their supported
    protocols in their preferred order:

    FileTransferSession (A) FileTransferSession (B)
    ---------------------- -----------------------
    supported_protocols: supported_protocols:
    1. "TCP/IP:xxx.xxx.xx.xx:yyy" 1. "Other:adafadfasdfd"
    2. "Other:adfadfasdfadfdf" 2. "TCP/IP:xxx.xxx.xx.xx:yyy"

    Even though they both support the same protocols, if these two
    FileTransferSessions attempt a transfer using the Code sample in
    Section 4.5.2, A will select TCP/IP, B will select "Other" and the
    transfer will never happen.

    Action Requested: specify transfer protocol selection method.

  • Reported: FTAM 1.0b1 — Tue, 30 Jan 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Use of Directory in transfer/insert/append/delete operations

  • Key: FTAM-12
  • Legacy Issue Number: 4179
  • Status: closed  
  • Source: DSTC ( Ted McFadden)
  • Summary:

    The interface Directory derives from File and can therefore be used as
    an argument in FileTransferSession::transfer/insert/append/delete calls.

    Directories are only mentioned in the description of delete. Is the delete
    of a directory recursive or must the directory be empty first?

    And what is the behavior of transfer,insert,append when one or both of
    the arguments are Directories? Is this legal at all?

    Action Requested: Specify behavior when a Directory is used as src or dest
    argument to transfer,insert, and append. Specify recursive behavior for
    those operations and delete.

  • Reported: FTAM 1.0b1 — Tue, 30 Jan 2001 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Architecture issue

  • Key: FTAM-9
  • Legacy Issue Number: 4055
  • Status: closed  
  • Source: Siemens AG ( Alan Burger)
  • Summary:

    9. Another issue is related to the architecture. We would like to provide a customer with an IDL for accessing server side file systems. The most important operation is a file transmission. In current design of FTAM/FTP Interworking there is a "transfer" operation that copies file between two Virtual File Systems. In this case customer will have to implement his VFS and a driver (or we will have to implement for him) and we afraid that from his point of view it may be not acceptable. I would like to know if an operation of FileTransferSession which just returns file contents is considered for FTAM/FTP RFP (i.e. operation that returns sequence of octets). In this case customer will not have to implement his VFS - the file contents will be retrieved by simple IDL operation

  • Reported: FTAM 1.0b1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    duplicate of issue 3821 – close issue

  • Updated: Fri, 6 Mar 2015 21:48 GMT

'delete' operation is C++ keyword

  • Key: FTAM-8
  • Legacy Issue Number: 4054
  • Status: closed  
  • Source: Siemens AG ( Alan Burger)
  • Summary:

    8. There is an operation defined in FileTransferSession interface called "delete" which is to delete the file in file system. The "delete" is a C++ keyword so it cannot be mapped from IDL to C++.

  • Reported: FTAM 1.0b1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    duplicate of issue 3820 - close issue

  • Updated: Fri, 6 Mar 2015 21:48 GMT

CommandNotImplementedException

  • Key: FTAM-7
  • Legacy Issue Number: 4053
  • Status: closed  
  • Source: Siemens AG ( Alan Burger)
  • Summary:

    7. It might be a good idea to declare that the operations delete and create_directory can throw a CommandNotImplementedException

  • Reported: FTAM 1.0b1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

The NativeFileSystemType enumeration has to be changed

  • Key: FTAM-6
  • Legacy Issue Number: 4052
  • Status: closed  
  • Source: Siemens AG ( Alan Burger)
  • Summary:

    6. The NativeFileSystemType enumeration has to be changed. It currently takes the form:enum NativeFileSystemType

    { FTAM, FTP, NATIVE }

    ; The keyword "native" is now used by CORBA, and the "NATIVE" element should therefore be changed to "LOCAL". A new element, "UNKNOWN", should also be added for drivers that do not fall into the three main categories.

  • Reported: FTAM 1.0b1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

ProtocolSupport struct

  • Key: FTAM-5
  • Legacy Issue Number: 4051
  • Status: closed  
  • Source: Siemens AG ( Alan Burger)
  • Summary:

    5. In the ProtocolSupport struct, the transport protocol used between FTS's is specified by the protocol_name member. It would be a good idea to specify values for more commonly used transport protocols, eg "TCP/IP" for TCP connections, "UDP/IP" for UDP, etc.

  • Reported: FTAM 1.0b1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

We should clarify the roles of sender and receiver

  • Key: FTAM-2
  • Legacy Issue Number: 4048
  • Status: closed  
  • Source: Siemens AG ( Alan Burger)
  • Summary:

    2. We should clarify the roles of sender and receiver, and make clearer which FTS actually initiates the transfer.

  • Reported: FTAM 1.0b1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

beef up the discussion of how the Property Service is to be used

  • Key: FTAM-1
  • Legacy Issue Number: 4047
  • Status: closed  
  • Source: Siemens AG ( Alan Burger)
  • Summary:

    1. We should beef up the discussion of how the Property Service is to be used, and remove duplications. For example, Name and CompleteName are both listed as attributes and as properties to be supported.

  • Reported: FTAM 1.0b1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Type name & parameter name should differ by more than just case

  • Key: FTAM-4
  • Legacy Issue Number: 4050
  • Status: closed  
  • Source: Siemens AG ( Alan Burger)
  • Summary:

    4. Type name & parameter name should differ by more than just case, thus "void delete(in File file)" needs to be changed

  • Reported: FTAM 1.0b1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

We need to discuss the protocols supported

  • Key: FTAM-3
  • Legacy Issue Number: 4049
  • Status: closed  
  • Source: Siemens AG ( Alan Burger)
  • Summary:

    3. We need to discuss the protocols supported, e.g., how are FTAM protocols
    registered? - stringified Application Entity Titles, or what?

  • Reported: FTAM 1.0b1 — Wed, 15 Nov 2000 05:00 GMT
  • Disposition: Resolved — FTAM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Encoding of Service Contexts in Fault Tolerant CORBA specification missing

  • Key: FT-7
  • Legacy Issue Number: 3908
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    13.6.7 of the CORBA 2.3 specification states: "The context data for a particular service will be encoded as specified for its service-specific OMG IDL definition, and that encoded representation will be encapsulated in the context_data member of IOP::ServiceContext. (See Section 15.3.3, Encapsulation, on page 15-13)."

    The descriptions of service contexts in the FT spec are missing an explicit statement of the encoding of the service context data.

    Proposed Resolution:

    Add the following sentence in all appropriate sections: "When encoded in a request or reply message header, the <code>context_data</code> component of the <code>ServiceContext</code> struct will contain a CDR encapsulation of the xxxxxx struct."

  • Reported: FT 1.0b1 — Mon, 25 Sep 2000 04:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Propose Remove use of Filter

  • Key: FT-6
  • Legacy Issue Number: 3856
  • Status: closed  
  • Source: AT&T ( Robert Gruber)
  • Summary:

    Motivation: The Notifier will be easier to replicate if it is a single
    object. At present, all Filters created by the Notifier must also be
    replicated. Furthermore, there is no requirement that a Filter be destroyed
    by the client that created it (once it is done using it), raising a garbage
    collection issue. FOr a connected consumer, if the consumer no longer
    exists the Notifier can discard the connection. There is no analagous test
    for Filters.

    The Notifier interface is already a collapsed version of multiple
    CosNotification APIs to get rid of the channel/admin/proxy objects in favor
    of one object, so I am just proposing we carry through on that approach.

    Óne proposal:

    First, remove method create_subscription_filter.

    Second, change the 2 connect_foo_fault_consumer methods
    (connect_structured_fault_consumer + connect_sequence_fault_consumer) to
    take just a consumer and a grammar:
    ConsumerId connect_foo_fault_consumer (in CosNotifyComm::FooPushConsumer,
    in string constraint_grammar)
    raises (ÏnvalidGrammar, AlreadyConnected)

    One or more event forwarding constraints is associated with each connected
    consumer, with the default being a constraint that matches all events. The
    ConsumerID returned from a call can be passed into methods that modify
    these constraints. When a consumer is disconnected, the associated
    constraints are discarded.

    Third add methods for manipulating constraints associated with a ConsumeID:

    string constraint_grammar(in ConsumerID)
    void add_constraints(in ConsumerID, ...)
    void remove_constraints(in ConsumerID, ...)
    void remove_all_constraints(in ConsumerID)
    void modify_constraints(in ConsumerID, ...)
    ConstraintExpSeq get_constraints(in ConsumerID)

    where ... means the normal arguments that are in the corresponding methods
    in the Filter spec.

    The above methods correspond to the Filter methdos that are required in the
    current version of the spec, except I left out 2 of them, match_structured
    and destroy. I do not think we need to support match_structured – only the
    Notifier needs to be able to do matching. destroy is not needed because
    there is no filter object to be destroyed. (disconnect is sufficient.)

    ALTERNATE PROPOSAL

    A simpler scheme is to associate a single constraint with each consumer.
    This is not very restrictive, especially when you consider that there is
    currently only one event type in use in the FT spec. The default would
    still be a constraint that matched all events. In this case the only method
    needed to modify this constraint is:

    void replace_constraint(in ConsumerID,
    in EventTypeSeq event_types,
    in string constraint_expression)

    Further, if we are willing to stick to the default constraint grammar, no
    grammar needs to be specified, which simplifies connect_foo_consumer – not
    only by removing the constraint_grammar argument but also by removing the
    InvalidGrammar exception, which comes from CosNotifyFilter. I believe one
    could simplify things enough to get rid of any dependencies on
    CosNotifyFilter. It is not clear how important this is, but I thought I
    should mention the possibility.

  • Reported: FT 1.0b1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue with 'factory'

  • Key: FT-5
  • Legacy Issue Number: 3778
  • Status: closed  
  • Source: Eternal Systems ( Louise Moser)
  • Summary:

    The Fault Tolerant CORBA specification contains the following struct.

    struct FactoryInfo

    { GenericFactory factory; Location the_location; Criteria the_criteria; }

    ;

    This causes a problem for the IDL compilers of some vendors, because
    "factory" is a keyword in CORBA V2.3. See CORBA V2.3, page 3-8, Lexical
    Conventions, June 1999.

    We need to change "factory" in this struct to "fact", "fctry",
    "generic_factory", or whatever. What is your preference?

  • Reported: FT 1.0b1 — Mon, 21 Aug 2000 04:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

define the State as typedef any State

  • Key: FT-4
  • Legacy Issue Number: 3747
  • Status: closed  
  • Source: Eternal Systems ( Louise Moser)
  • Summary:

    The Fault Tolerant CORBA specification defines the State used by the
    get_state(), set_state(), get_update(), set_update() methods, as

    typedef sequence<octet> State

    Those methods must be implemented by the application programmers.
    They will find their task easier if we define the State as:

    typedef any State

  • Reported: FT 1.0b1 — Tue, 18 Jul 2000 04:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

following question regarding modifications to CORBA core

  • Key: FT-3
  • Legacy Issue Number: 3516
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    Basically, the Failure OBJ_ADAPTER is considered a failover condition in the
    document that was sent out. In most cases OBJ_ADAPTER exception may be thrown
    when there is an internal ORB error. In case of an internal ORB error, the
    retry on the TAG_ALTERNATE_IIOP_ADDRESS may still yield the same exception. This
    may be inefficient. Do you see situations where doing a failover on this
    particular exception is useful.

  • Reported: FT 1.0b1 — Wed, 29 Mar 2000 05:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    Remove OBJ_ADAPTER from this list.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

On page 27-9 of the FT CORBA spec, under "Application-Controlled Membership

  • Key: FT-11
  • Legacy Issue Number: 4109
  • Status: closed  
  • Source: Eternal Systems ( Louise Moser)
  • Summary:

    On page 27-9 of the FT CORBA spec, under "Application-Controlled Membership",

    "The application-controlled (MEMB_INF_CTRL) Membership Style"

    should be corrected to read

    "The application-controlled (MEMB_APP_CTRL) Membership Style"

  • Reported: FT 1.0b1 — Thu, 30 Nov 2000 05:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    Correct the above statement with the revised text given below.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

term "method" used wrongly

  • Key: FT-10
  • Legacy Issue Number: 4066
  • Status: closed  
  • Source: Credit Suisse ( Wolfgang Schulze)
  • Summary:

    Throughout the document, the authors use the term "method" several times where they should be talking about "operations" instead. This violates the general understanding of the OMG terminology, where IDL interfaces contain "operations", not "methods". The term "method" is usually reserved as a concept of oo programming languages.

    I recommend that for the next revision, the authors run a global search&replace and identify where they want to talk about methods and where of operations.

  • Reported: FT 1.0b1 — Mon, 20 Nov 2000 05:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Harmful deprecation of LOCATE_FORWARD_PERM for Faut Tolerant CORBA

  • Key: FT-9
  • Legacy Issue Number: 3976
  • Status: closed  
  • Source: Alcatel-Lucent ( Julien Maisonneuve)
  • Summary:

    Earlier this year, the interop FTF deprecated the LOCATE_FORWARD_PERM
    exception because of several reasons :

    • it was badly specified
    • it made the implementation of hash() difficult, and broke most of the
      existing ones.

    It turns out that the Fault Tolerance specification published a little
    earlier crucially requires a similar mechanism.
    In normal life, most applications can rely on plain LOCATE_FORWARD because
    there is no reason to expect the death of the originally pointed component.
    In the case of Fault Tolerant CORBA, this is entirely different: it is
    precisely when we issue a LOCATE_FORWARD_PERM that we know for sure that
    the original component is dead, and might never return. If all the backup
    profiles of an IOR enjoy the same death, all hope is gone.

    This means that without a mechanism similar to LOCATE_FORWARD_PERM, the
    Fault Tolerant CORBA spec cannot address the requirements of real
    fault-tolerant systems.

    This is why the Fault-Tolerant CORBA FTF would like to see LOCATE_FORWARD_PERM
    re-introduced in some way. Here are a few ideas that might help :

    Issue of scope:
    The scope of LOCATE_FORWARD_PERM is ORB lifetime.

    Issue of hash() :
    Let us be reminded that the Fault-Tolerant CORBA spec defines teh concept of
    an Interoperable Object Group Reference (IOGR). The IOGR contains a specific
    profile that contains a group identifier.

    • When an ORB receives and IOGR, it should compute the value of hash() based
      on the GroupID contained in the IOGR, and performs LOCATE_FORWARD_PERMs if
      requested.
    • When an ORB receives a normal IOR (i.e. an IOR lacking a group profile) it
      computes hash() in the customary way, and doesn't have to respond to
      LOCATE_FORWARD_PERMs.
  • Reported: FT 1.0b1 — Thu, 19 Oct 2000 04:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

typedef issue

  • Key: FT-8
  • Legacy Issue Number: 3910
  • Status: closed  
  • Source: Eternal Systems ( Louise Moser)
  • Summary:

    One additional issue I have is that the
    ReplicationStyleValue, MembershipStyleValue, ConsistencyStyleValue,
    FaultMonitoringStyleValue, FaultMonitoringGranularityValue
    are typedefed to long, whereas the
    InitialNumberReplicasValue and MinimumNumberReplicasValue
    are typedefed to unsigned short. It might be more appropriate
    to typedef all of these to unsigned short.

  • Reported: FT 1.0b1 — Mon, 25 Sep 2000 04:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT