Issue 4055: Architecture issue (ftamftp-ftf) Source: Siemens AG (Dr. Alan Burger, ) Nature: Uncategorized Issue Severity: 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 Resolution: duplicate of issue 3821 -- close issue Revised Text: Actions taken: November 15, 2000: received issue Discussion: End of Annotations:===== 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 Date: Tue, 20 Feb 2001 16:39:41 +1000 From: Ted McFadden To: ftamftp-ftf@omg.org Subject: Comment on issue 4055, 3821: Architecture Issue / Server Access Message-ID: <20010220163941.D10708@ooc.com.au> Mime-Version: 1.0 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: IGG!! To: ftamftp-ftf@omg.org, "'Ted McFadden'" Subject: RE: Comment on issue 4055, 3821: Architecture Issue / Server Acce ss Date: Tue, 20 Feb 2001 18:31:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-UIDL: 8_&!!2@/!!$,Z!!9Mfd9 But everybody has FTP. Why use CORBA to pump large amounts of data, when FTP does the job fine. I think that a CORBA response with a 35 MB message size seems unattractive to me. Tom Rutt terutt@lucen t.com ter ---------- From: Ted McFadden [SMTP:tmcf@ooc.com.au] Sent: Tuesday, February 20, 2001 1:40 AM To: ftamftp-ftf@omg.org Subject: Comment on issue 4055, 3821: Architecture Issue / Server Access Hi, Comment on ftam/ftp issue 4055, 3821: Architecture Issue, Accessing Server Side File Systems --------------------------------------------------------- Issues 4055, 3821 appear to refer to overlap. I have to agree with the original submitter of this issue, Marcin Przysowa [SMTP:mprzysow@bya1c16.pl.lucent.com], that it is highly desirable to allow a client to read / write a file without having to implement a (limited) FileTransferSession object to do so. Forcing a client to implement a server object requires the client to act as a mixed corba client and server, which requires an orb's server side support to be present (linked in). Since the specification does not allow for using CORBA to actually perform the file transfers, this also burdens pure client applications with writing and testing protocol handlers. A new handler would have to be written each time a new file system supported_protocol is encountered. It should be possible to add interfaces that allow for a pure client to read or write to a File using a CORBA interface. Providing such an interface would allow any two Virtual File Systems to transfer files because at a minimum they would both support the `corba protocol', in addition to "tcp" or whatever. This would help address issue 4056, concerning protocol bridges. Cheers, Ted -- Ted McFadden tmcf@ooc.com.au Object Oriented Concepts Inc. - An IONA Company http://www.ooc.com Suite 4, 8 Martha St. +61-7-3324-9633 Camp Hill, Brisbane, 4169, QLD. Australia Date: Wed, 21 Feb 2001 11:16:09 +1000 (EST) From: Michi Henning To: "Rutt, T E (Tom)" cc: ftamftp-ftf@omg.org, "'Ted McFadden'" Subject: RE: Comment on issue 4055, 3821: Architecture Issue / Server Acce ss In-Reply-To: <4490F7068AC0D111A7120008C72878EC085E69D5@nj7460exch003u.ho.lucent.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: LKT!!$i[!!))Wd95)""! On Tue, 20 Feb 2001, Rutt, T E (Tom) wrote: > But everybody has FTP. Why use CORBA to pump large amounts > of data, when FTP does the job fine. > > I think that a CORBA response with a 35 MB message size seems > unattractive to me. Tom, no-one is talking about sending 35 MB messages with CORBA here. Naturally, file contents are transferred in smaller chunks. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi@ooc.com.au Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: "Rutt, T E (Tom)" To: "Rutt, T E (Tom)" , "'Michi Henning'" Cc: ftamftp-ftf@omg.org, "'Ted McFadden'" Subject: RE: Comment on issue 4055, 3821: Architecture Issue / Server Acce ss Date: Tue, 20 Feb 2001 22:26:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-UIDL: /p!e9D4:!!lped9*m!"! If you send each File segment in a separate corba message, you are re-inventing a file transfer protocol. With the ubiquity of FTP why do this? Tom Rutt ter ---------- From: Michi Henning [SMTP:michi@ooc.com.au] Sent: Tuesday, February 20, 2001 8:16 PM To: Rutt, T E (Tom) Cc: ftamftp-ftf@omg.org; 'Ted McFadden' Subject: RE: Comment on issue 4055, 3821: Architecture Issue / Server Acce ss On Tue, 20 Feb 2001, Rutt, T E (Tom) wrote: > But everybody has FTP. Why use CORBA to pump large amounts > of data, when FTP does the job fine. > > I think that a CORBA response with a 35 MB message size seems > unattractive to me. Tom, no-one is talking about sending 35 MB messages with CORBA here. Naturally, file contents are transferred in smaller chunks. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi@ooc.com.au Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Wed, 21 Feb 2001 13:30:54 +1000 (EST) From: Michi Henning To: "Rutt, T E (Tom)" cc: ftamftp-ftf@omg.org, "'Ted McFadden'" Subject: RE: Comment on issue 4055, 3821: Architecture Issue / Server Acce ss In-Reply-To: <4490F7068AC0D111A7120008C72878EC085E69D8@nj7460exch003u.ho.lucent.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: c-Zd9F!O!!,BCe9)29e9 On Tue, 20 Feb 2001, Rutt, T E (Tom) wrote: > If you send each File segment in a separate corba message, you are > re-inventing a file transfer protocol. With the ubiquity of FTP why > do > this? The FTP-FTAM spec is about providing CORBA access to virtual file systems. The way it is written, the client must have built-in support for FTP or FTAM, which begs the question what CORBA is doing in this picture to start with. The aim should be to allow a CORBA client to access files that are on such a virtual file system without having to know about the various protocols involved (that is, a pure CORBA client should be able to do file transfers). When you look at comp.object.corba, you will find that one of the most commonly asked questions is: "How can do file transfer with CORBA?" Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi@ooc.com.au Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Date: Thu, 24 May 2001 10:00:03 +1000 From: Ted McFadden To: ftamftp-ftf@omg.org Subject: Correction to FTAM-FTP vote 1: Issue 4051 should be 4055 Message-ID: <20010524100003.B29840@iona.com> Mime-Version: 1.0 X-Mailer: Mutt 1.0i Content-Type: text/plain; charset=us-ascii X-UIDL: D*j!!/?@!!`f;!!]JSd9 Hi, I made a mistake in referring to Issue 4051 for voting. Issue 4051 deals with the ProtocolSupport struct. No vote is proposed for 4051 at this time. This should have been Issue 4055: Architecture Issue. The vote is still the same, simply to close it as a duplicate of 3821. Please replace the vote item #2 with: ---------------------------------------------------------------------- 2. Issue 4055 - This appears to be essentially the same as issue 3821. The vote is whether to close it as a duplicate of 3821. A NO vote means that it is not a duplicate, should not be closed, and needs to be addressed independently. A YES vote means it is a duplicate and should be closed with no action. ------------------------------------------------------------------------ Cheers, Ted -- 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