Re:Re: Some general facts about panel and gnome

[Hassan Aurag <aurag CRM UMontreal CA>]

 Hi,
 
 I am not en expert at these things, nut I think that the ones who really care 
about that kind of stuff are people who use Linux/Gnome on a single machine at 
home or maybe two, the other being some version of Windows.
 
 So really, even though this would be fine, I don't think one should expect all 
possible file opening protocols to be supported.
 
 An application might use scp to bring on a file (temporarly) and open it, or it 
might be ftp, or http or uucp or rsh or telnet/setenv DISPLAY or ......
 
 The whole idea however should be that this must be handled by the given app.
 If I am opening a file remotely somehow then register that file as having a 
special mime-type like file/x-remote-text that will be handled by the owning 
app.
 
  The opening app (mime program) should have registered all necessary info on 
how to get this file.
  
  Eg(imaginary): I am planning on allowing people to run something remotely 
(rsh), opening a file there and dumping results elsewhere. User X views those 
files using my app (I use scp, dump it in /tmp as some crazy name and open the 
local gnumeric to show bonobo components located on another machine ... itself 
mounting the said filesystem using NFS, the last said machine needing to gather 
its pieces (/etc/rc.d/*) from 500 other subnets using 1000 different protocols ) 
Well dump the file name in recently accessed files with a special flag ( a 
symbolic link to an app created .ini type file or whatever that launches the 
correct procedure to open that file and look at it). In other words, this must 
be handled by the app. Dump some intelligent name and link this to some .ini or 
.rc file that knows what to do!
> Resent-Date: 19 Jan 2000 13:26:19 -0000
> Resent-Cc: recipient list not shown: ;
> MBOX-Line: From gnome-devel-list-request@gnome.org  Wed Jan 19 08:26:19 2000
> From: allbery@ece.cmu.edu
> Date: Wed, 19 Jan 2000 08:26:02 -0500 (EST)
> Subject: Re: Some general facts about panel and gnome
> To: miguel@gnu.org
> cc: jirka@5z.com, gnome-devel-list@gnome.org
> MIME-Version: 1.0
> Resent-Message-ID: <"6-mRj3.0.Mv4.xjRXu"@lists.redhat.com>
> Resent-From: gnome-devel-list@gnome.org
> X-Mailing-List: <gnome-devel-list@gnome.org> archive/latest/1810
> X-Loop: gnome-devel-list@gnome.org
> Resent-Sender: gnome-devel-list-request@gnome.org
> X-URL: http://www.redhat.com
> 
> On 18 Jan, Miguel de Icaza wrote:
> +-----
> | > > One problem with the whole recently-used-files thing is that 
> | > > we don't assume the user uses GNOME from only one machine, so there
> | > > are multiple file namespaces. I'm not sure what to do about that at
> | > 
> | > Well with vfs, this should take care of itself really.
> | 
> | Not really.  Even if you have the hostname, that does not mean you
> | will have a way of accessing the files remotely.  
> +--->8
> 
> This should be a user- and/or site-defined policy.  For example, here I
> can access an on-campus host's files via encrypted FTP... or if it's in
> AFS I can access it as if it were a local file.
> 
> So here's what you do:  hand file://(?!localhost)([^/]+)/ off to a
> script.  The GNOME default script would either fail gracefully or
> attempt FTP, etc. (or maybe even attempt AFS and NFS if /afs and/or /net
> mountpoints exist); site administrators could then customize it to do
> the appropriate thing, which could involve FTP, scp, magic, whatever.
> 
> -- 
> brandon s. allbery      [os/2][linux][solaris][japh]     allbery@kf8nh.apk.net
> system administrator         [WAY too many hats]           allbery@ece.cmu.edu
> electrical and computer engineering                                      KF8NH
> carnegie mellon university        ["better check the oblivious first" -ke6sls]
> 
> 
> -- 
> To unsubscribe: mail gnome-devel-list-request@gnome.org with "unsubscribe"
> as the Subject.
>