Re: RE : GSMBrowser.

[Peter Cooper]

> >Actually, it would be nicer to have this functionality available
> >throughout the system, which probably means something like a fairly
> >standardised way of mapping new mechanisms for file access into GS base.
> >
> 
> What about using URLs? You can have samba://foo/bar, cvs://, file://, or 
> even mail://mailbox/message_id where mailbox is abstract mailbox defined by 
> GNUmail for example. URL is more general than file reference. From 
> programmers poit of view initWithURL should be prefered instead of 
> initWithFile:

I don't want to start any religious wars here ;) however, while URIs are
a very powerful way of describing long-term resource locations (amongst
other things), they have enough internal structure to confuse most users.

People who want to open or save a document are seldom interested in
constructing a protocol://system/path/name.extension tuple. Even through
a GUI. Let's face it, for the "mission oriented" user (ie they've got a
job to do), browsing a directory tree is hard enough. And even when, like
on a GNUstep system, it's fairly rationally organised!

I agree with use of URLs widely, but if possible more naive interfaces
should still be deployable. And there's little simpler than a rooted
tree (other than my father's huuuuuuuge "My Documents" directory ;)

Certainly making sure that URIs can be used everywhere a filepath might
be would be a very useful feature.

> UNIX idea of single file tree is not bad, but i think that URLs have their 
> advantages too. You can have several DO servers or apps handling various 
> URL types, like SMBBrowser for samba://, GWorkspace for file// or 
> Teminal.app for telnet:// . Each application/tool can handle its own 
> preferences and will provide its specific functionality. Moreover, URL 
> handlers can be user-configurable.

It sounds good.

> Regarding to using native file access... I think that plain file reference 
> as it is widely used now should be soon or later deprecated in the favor of 
> more general URL. For this, some decent way of URL chooser (like open/save 
> panel) is needed... or just using Workspace for the functionality of URL 
> chooser panels.

Maybe it's my old Mac support background but the word "Chooser" fills me
with fear :) You're probably right about traditional trees fading away,
but until we get some fairly good UI paradigms (better than clicking
underlined blue text, anyway) it's a little way away.

> I agree. What about various subclasses of NSFileManager like 
> SambaFileManager, FTPFileManage or CVSFileManager implemented as DO servers 
> or applications? There should be one server for NSFileManager functionality 
> and one for NSWorkspace's openURL:. They can be in one app or separate...

I was thinking along similar lines: a set of bundles offering per-user
functionality *via* existing classes - and configuration pulled out of
the user's defaults - and loaded on demand to provide the functionality
themselves, or despatching requests via DO to another process if necessary.

But there should be no essential requirement to do this with additional
processes in the general case. 

> >But what is the best way of actually adding this kind of functionality?
> >
> 
> By using URLs we do not have to muckle with file system hierarchy and 
> tools. Moreover, it will be users choice for tools for handling url types. 
> What about some user condigurable DO server/broger which will provide 
> information about url handlers (other DO servers)? One will ask for object 
> that can handle samba url types and will get SMBBrowser or any other tool...

I'm not proposing to meddle with underlying operating system filesystem
details - just mapping "virtual paths" onto the real directory structure
if the user configures the extension. I'm actually not even proposing 
much (if any) meddling with base classes - an extension library might
be able to do this using categories. Then existing software should be
able to use this functionality out of the box.

My question is: how would I go about getting this library to override 
selected base classes? LD_PRELOAD and categories? Is LD_PRELOAD too Unix-
variant specific?

> GNUstep with its advantage of cooperating objects can do all this. It can 
> do more than using programs for processing text output using pipes...
 
I agree. But: Objective-C with it's ability to extend existing code at
runtime could do something like this with a fairly low overhead, I think.

> Just thinking...

Good thinking!

Peter