Re: Thinking about GtkFileSystem

[Alexander Larsson <alexl redhat com>]

On 14 Mar 2003, Owen Taylor wrote:

> On Fri, 2003-03-14 at 08:44, Alexander Larsson wrote:
> 
> > One thing that is totally left out of this is Authentication. For any 
> > non-trivial filesystem implementation that does remote shares you will 
> > need to at least enter username/password, and often more (domain, key 
> > phrases etc). Furthermore, it would be very painful for users if each app 
> > had to authenticate, as the user would have to type username + password in 
> > each app reading files from a protected share. Any sane system must have a 
> > "daemon" process that remembers the entered passwords and pops up 
> > authentication dialogs when needed.
> > 
> > Now, how will this be affect the API? Well. It means that any blocking I/O 
> > call could potentially block for a very long time, waiting for user input. 
> > If the file dialog just used blocking calls this could stop the whole app 
> > from even repainting while the auth dialog is up. I think this means we 
> > have to go with an async I/O model. This ties up with some of the things 
> > discussed below.
> 
> The other thing that you'd like is the ability set the right transient
> parent ... same thing as I mentioned for error dialogs.

Ah, yeah.
 
> > Due to the auth issues discussed above maybe we should have an async stat.
> > I'm not sure how this would look. Perhaps the file_changed, file_added 
> > (and file_exists if we add that) signals on the monitor object could pass 
> > in a GtkFileInfo with the new data. 
> 
> I don't particularly see why authentication would require an 
> async _stat_. Isn't authentication typically on a per-folder
> basis?

Thats true in this case I guess, since we can guarantee to always read the 
directory before stat:ing any files in it.


> > What about a "created" signal? If you start monitoring something that 
> > doesn't exist? Fam goes into polled mode for active monitors on files that 
> > doesn't exist (since dnotify need the file to exist to work).
> 
> What would be the use case for monitoring something that doesn't
> exist? I would think:
>  
>  A) We wouldn't allow the file selector to be pointed at
>     a non-existent location.
>  B) If the directory the file selector was looking at vanished
>     we'd change it to the "closest" existent directory.

I agree.
 
> > You might want to share folder data between several folder monitors 
> > though. If we add a "file_exist" signal to the monitor that means the 
> > monitor has "state" for the user, and each user must create a private 
> > monitor object.
> 
> Hmm. That can, I think, be left as an implementation detail. For 
> GtkFileSelector, we probably can just get away with taking the
> overhead if there are multiple instances monitoring the same
> directory.
> 
> But that does make clear to me why I'm a bit uncomfortable with the
> everything-async model ... it means that the monitor object
> becomes stateful and no longer has a meaning independent of
> past history. 

Yes. That certainly makes it much more complex.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's an old-fashioned chivalrous photographer living undercover at Ringling 
Bros. Circus. She's a bloodthirsty psychic magician's assistant from a secret 
island of warrior women. They fight crime!