Fwd: RFC for a better Network place.

[Sebastien Estienne <sebastien estienne gmail com>]

Sorry didn't replyed to the mlist


---------- Forwarded message ----------
From: Sebastien Estienne <sebastien estienne gmail com>
Date: Tue, 1 Feb 2005 16:48:36 +0100
Subject: Re: RFC for a better Network place.
To: Alexander Larsson <alexl redhat com>


On Tue, 01 Feb 2005 11:51:43 +0100, Alexander Larsson <alexl redhat com> wrote:
> On Tue, 2005-02-01 at 02:00 +0100, Sebastien Estienne wrote:
> > Hello,
> >
> > I'd like feedback about speeding up network place browsing, and adding
> > functionality to offer a more consistant and faster experience in
> > network browsing.
> >
> > first problem:
> >  it's always slow to display the first entry when you launch network
> > place, it starts empty and you have to wait 4/5 seconds before seeing
> > anything
> > even if you have just browsed the network 10 seconds ago, maybe it would
> > needs some kind of caching to offer a better experience to users.
>
> This is likely the delay from the initial smb browse lookup.
> 
Right but is it really necessary that we have to wait for it everytime
that we open network places, could we use some kind of cache to first
have the result of the last browse, and then have it updated when the
browse is finished. The annoying things is that it starts blank, even
if i closed it 1 second ago

> > I was thinking about implementing this functionality in a deamon. The
> > deamon would periodically browse the network (could also browse for
> > zeroconf services). And exports it's findings throught dbus.
>
> network already browses for zeroconf services. Moving the network method
> to the gnome-vfs daemon is a one line configuration change.
> 
Yes i knew that it already browsed zeroconf things, but didn't know
that there were already a deamon.
If it's configurable, when is it better to have the gnome-vfs not do
the browsing part?

> > In this schema "network place" would talk to the deamon using dbus,
> > and the browsing would answer immediately.
>
> Why use dbus and a new daemon when we already have a vfs daemon.
Sorry, i didn't know the existance of the gnome-vfs deamon. In fact i
tried to find some documentation about the design of nautilus and
found almost nothing. so i was just guessing. Dbus was just a way to
communicate with this deamon. But if it already exists.
Could you enlight me about the way smb browsing works in nautilus, is
it already the deamon that browse for shares/computer/workgroup.
Is browsing in background, or only when user asked him to browse?
does it cache previous result?

>
> > second problem:
> > the display feel unconsistant: you have workgroup, computers, shares,
> > ssh share, nfs and so on. All at the same level without any logic in
> > there placement.
>
> There is some logic. All the local shares (link-local mDNS services,
> dns-sd services in your domain, computers in your workgroup) are in the
> toplevel network browser. There is also links to the windows network for
> smb browsing, and separate links to toplevel dns-sd domains if any are
> configured.
Ok i get it, but what i find disturbing is that at the same level (top
level) you have computers and shares, and these computer contains
other shares.

so, what about not displaying these computer but only the shares they
contrains on top level (like it's done for zeroconf ftp/dav)?

instead to click on computer COMP, and then see share MYSHARE, we
would see on top level: MYSHARE on COMP, a bit like it's don't for
webdav (ALex's share)

We could rename "windows network" into "network browsing" and these
computer that we removed from top level would be inside "network
browsing".
so insted of seeing computer in our workgroup directly in top level,
they would be in browsing network, with other workgroup.

and maybe this new "network browsing" could also be used to browse
zeroconf network (not sur if this notion exist in zeroconf link-local
networking??)

>
> > Maybe we could sort them a bit.
> > Maybe separating windows/samba browsing from other shares.
> >
> > it seems to be 3 types of network ressources:
> > - samba/windows : windows workstation, workgroups samba shares:
> > - zeroconf detected services: webdav/ftp
> > - user defined shares : dav/ftp/nfs/ssh
>
> The location of user defined shares in network is a patch that Ubuntu
> has applied that I have already rejected. The original model as
> described in my first mail on this considers "connected servers"
> essentially like local storage and thus appears in Computer. Since
> Ubunty called its "Computer" menu "Disks" they decided to move the
> connected servers to the Network location.
thanx for the precision, didn't know this either

>
> > Maybe we should try thinking of a "better" way to organize them?
> > Maybe a simple separation would be enought, or maybe we could separate
> > "browsing" from "favorites" places. I don't have a perfect solution
> > for the moment, but i'm sure it needs some works! :D
>
> Its possible that it can be organized better, but i'm not sure how.
to find a solution i tried to look at other Os namely windows and mac
->windows XP, only care about smb browsing , a bit of webdav and ftp.
they also keep some kinds of favorite (the last shares that you connect on)
and this is a bit organized using a thin line to separate this in the
same window.
But i think that the way windows 98 or 2000 did it was easier to use
and understand:  networks -> workgroup -> computer -> shares

->mac looks a lot like gnome (or vice versa)  but face the same
problem trying to marry windows shares with unix one.

>
> "Favourites" is something else, eventually we'll add the the bookmarks
> from the gtk+ file selector to something like the places menu in
> nautilus.
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander Larsson                                            Red Hat, Inc
>                    alexl redhat com    alla lysator liu se
> He's an underprivileged Jewish senator in drag. She's a bloodthirsty tomboy
> cab driver on her way to prison for a murder she didn't commit. They fight
> crime!
>
>


--
Sebastien Estienne


-- 
Sebastien Estienne