[Win32utils-devel] network drives

[Zach Dennis]

Berger, Daniel wrote:

> That looks nice.  I'm wondering if we should have an all encompassing
> "win32-drive" package that includes this and the driveinfo stuff from
> Heesob.  That might make compatibility with Mike Hall's "filesystem"
> package more of a pain, though.
> 
> Any thoughts?

I'm not stuck on my mentioned implementation, I just wanted to get out 
what I was thinking so we had a better chance of being on the same page 
discussing things. I like clear-all-out-in-the-open-communication. =)

On a quick side note, Mike needs to update his link on the RAA. He say 
he has version 0.5 which was released June of last year, yet the 
download links is for 0.3. So my comments will be on his 0.3 documentation.

The filesystem package appears to only give you information on a 
filesystem, but doesn't let you do anything about it. I think Park 
Heesob's recent work would be more of the stuff to keep compatible with 
the filesystem package, and depending on where you wanted to allow the 
functionality to connect network drives would determine if you'd be 
expanding the filesystem package or if it'd be another package in 
win32-drive.

The mounting of network resources could be handled low level making win 
api calls or as an interface to the 'net' command, since I believe all 
versions of windows have 'net'.

I like the idea of interface compatibility, since I'm a windows and *nix 
user it's nice to think of consistent naming conventions.

I think that FileSystemMount is a misleading name though in Windows. 
FileSystemMount appears to be an object wrapping an actual mount point, 
and providing user information based on the methods; device, mount, 
fstype, etc..

mount also seems like the method to mount the network drive, and 
FileSystemMount sounds like the place you'd do that.

win32-drive::FileSystemMount.mount( 'v:', 'ComputerName', 'ShareName' )

seems intuitive don't it? Now I haven't used the 'filesystem' package so 
perhaps you can do something like that. If we keep existing 
functionality, I'd say we expand on it if it makes the best design decision.

If the methods; connect, disconnect were added to FileSystemMount I'd 
think we could get away with keeping interface consistency with the 
filesystem package and not giving methods duplicate behavior. If I want 
to map a network drive I'd like to create a FileSystemMount object and 
call 'connected?' or 'mounted?' to see if it's connected, otherwise i'd 
like to 'mount' it or 'connect' to make it so.

What your guys's thoughts?

Zach