On Mon, Feb 07, 2005 at 02:51:00AM +0100, Sven Neumann <sven@xxxxxxxx> wrote:
> Hi,
>
> <pcg@xxxxxxxx ( Marc) (A.) (Lehmann )> writes:
>
> >> Would you mind to explain what sort of problems that would be? If we
> >
> > mozilla ./file
> >
> > => file not acesssible (permission denied, other user, inaccessible dir)
> > => file not accessible (different machine)
> > => file not acesssible (different filesystem view)
> >
> > Assuming that a process has exactly the same view of the filesystem
> > as any other is in general not true. Comparing hostnames helps
> > somewhat in the first case.
>
> I see the point. But it would be trivial to take care of this,
> wouldn't it? The remote protocol would have to check if the instance
> of gimp that is already running on the current X server is a local
> process or not. Did I miss something obvious?
Yes, you miss the first and last error causes given above. A "local"
process proves nothing about file accessibility.
Think about it, X11 is a networked environment. Processes share an
X-display, but not the filesystem view. Linux for example provides each
process with it's own filesystem view, and this is expected to be used
more and more in the future.
The only save protocol would be to tansfer the file contents and name through
the x-server (a selection for example), and keep the gimp-remote around to
receive the file on saves, which is an awkward solution.
I think having the option of using "gimp-remote" with clearly defined
limitations (same filesyetm view required) and using "gimp" to ensure
correctness is preferable over some heuristic that gets it right for 95%
of the users or so. What advantage does an integrated solution bring? As
far as -i can see, it's only badly written programs that mindlessly
use "gimp" when they should offer the option of using either gimp or
gimp-remote.
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@xxxxxxxx
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
