[jcifs] Re: Abstract File(File, SmbFile) and enhanced Servlet application

[Eric]

> 
> Ahh, ok. I thought that was Rolfs post. I'll have to look at each closely
> and compare. Would it be benifical for SmbFile to implement a "File"
> interface?
> 

Possibly; but this would typically be done as part of a larger framework 
(i.e., a provider implementing some framework's interface, using jCIFS 
as the backing implementation).  Defining a "file" interface just to 
have SmbFile implement it is somewhat limited in use, since java.io.File 
etc. doesn't implement the interface.  If an external 
application/framework already supplies such an interface for providers, 
it would be typically be more appropriate to implement a wrapper for 
both SmbFile and java.io.File.  This is effectively what both of the 
code samples do; define an interface (or in Rolf's case, an abstract 
class), then define implementations for SmbFile and java.io.File.

This is useful functionality (I've looked at doing similar extensions 
for Davenport, to allow pluggable filesystem providers); it would just 
typically reside in a layer "above" jCIFS.  But if others would find it 
useful, I don't have any problem with it.  IMHO, an interface provides 
more flexibility than an abstract class (as it doesn't take up the 
single inheritance slot).  But either is okay by me, as long as it 
doesn't break existing functionality (naturally).


Eric