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

[Rolf Breuning]

Hello,

I agree that the best solution would be an interface, enhanced by one 
real object which holds a dictionary of schemes (smb:// file:// ...) and 
factories and thus allows to create instances of the various kinds of 
files.

This, however, is - a Eric stated - more an extension unconnected to 
jcifs. It needs much thinking off what such a kind of abstract file 
really is, the java.io.File class may be a good start, but as you see 
from the "canonical name" and the "directory / file / other smb entity" 
consideration, java.io.File is not quite enough. I personally would like 
to see such a thing in Java, but I am not in a position to start a Java 
Community Extension proposal, which would be the best thing to get to a 
unified solution.

That is why I proposed an abstract class with inner classes: I don't 
forsee that it is easy to solve the large problem, thus I proposed a 
"minimal invasive" addition to jcifs, an here the abstract class has the 
advantage of being a 1 file solution. Adding further capsules is 
possible though in fact that is only an idea. I don't see the 
inheritance here as a big issue, because you will want any other 
potential file class in any case remain in their domain and only to have 
the wrapper.

One might have small objections against the generic proxy approach 
because of performance, but most probably for the file interface that is 
not that important - it indeed reminds me of the nice things one could 
do in Smalltalk using #doesNotUnderstand: :-)

So IMHO we end up with some possible solutions:

   1. Integrate the abstract class in jcifs.
   2. Integrate the generic solution in jcifs.
   3. Strive for some larger solution

I forsee that 3. is a very tedious, but I'm not that experienced in 
freeware creating / handling, may be you can give your ideas on that.

If 3. is too big I still would like to see a solution for jcifs be it 1 
or 2 or a combination. But that would then most probably remain a pure 
jcifs related solution.

Rolf

Eric schrieb:

>> 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
>
>
-------------- next part --------------
HTML attachment scrubbed and removed