Polymorphic Abstraction of Disk versus FTP File Access: A Stumbling Block

I was chugging right along. I had a File access class which had all the methods of our FTP access class. You could call size(), exists(), etc. And it didn't matter whether you where accessing an FTP server or a local file.

Then all my fun came to an end.

With files, the option to read at on offset is exercised after the file is open via a seek. While FTP servers, the option to read at an offset is exercised via the REST command prior to opening the file.

Usually polymorphism, just means calling the same method and having the instance do the right thing. Here, polymorphism must span a series of API calls to work right. Ie,

$file->open;
$file->seek;
$file->read;

## must translate to open, seek, read for files
## must translate to REST, RETR for FTP
[download]

Comment on Polymorphic Abstraction of Disk versus FTP File Access: A Stumbling Block Select or Download Code

Replies are listed 'Best First'.
Re: Polymorphic Abstraction of Disk versus FTP File Access: A Stumbling Block by btrott (Parson) on May 22, 2001 at 05:05 UTC
Perhaps this is an indication that your API needs to be reworked slightly? In a generalized, transparent API like you're creating, maybe it's best not to require using relatively low-level methods like seek, open, read, etc. In other words, perhaps you should be thinking of a way to unify the filesystem API and the FTP API; it seems you've been able to do so relatively well so far, but now you've hit a stopping point: so you should step back and think whether your API for this particular operation is really the best possible API. If you can't seek FTP files, then why have a seek method in your API? That's specific to open filehandles, so it shouldn't be part of your general API. As an alternative solution, consider this: maybe your new method, or your open method, should take an argument specifying where in the byte stream the file should be opened. The local-file implementation could then do `open FH, ... seek FH, ...` [download] to get to the proper spot, and the FTP implementation could do `REST` [download] or whatever it is that you need to do for FTP. This approach might be sufficiently general that you won't get into the same problem of an implementation that cannot possibly fit into your API, because your API was not general enough to begin with.	[reply] [d/l] [select]
(tye)Re: Polymorphic Abstraction of Disk versus FTP File Access: A Stumbling Block by tye (Sage) on May 22, 2001 at 05:02 UTC
Of course, you can redesign your API. Another alternative is have FTP::open do what checking it can but delay actually requesting the file until a FTP::read or FTP::seek happens. A third alternative is to have FTP::seek reopen the file. - tye (but my friends call me "Tye")	[reply]