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.