Usability enhancements for VFS

[GoogleCodeExporter]

1. Hosts are sorted by online/offline status and then alphabetically. So,
it's hard to find the host under interest. It should be some way to filter
hosts by the first letter. Alphabet splitting should be whether
configurable, or automatically chosen to fit all the selected hosts into
single page (it could be up to twice longer than ordinal pages). Filtering
links should be shown at page top in form of (urls are for example):
<a href="0g">0 1 a b f g</a> <a href="hh">h</a> <a href="kz"k l m s u v w y
z</a><br />
This will not solve a problem with many-many hosts with name like
host-XXXXX.msu, but such hosts are not so interesting in contrast to hosts
which are moved from page to page due to changing a number of online hosts.

2. (alternative to 1, but could be implemented along with 1) The most
interesting shares are contain many information, so we could add sort
criteria between online-offline status and sharename. The criteria should
place shares with size>1Tb first, then shares with size>10Gb and all other
shares at last. More easy is to place shares with
size>(FIRST_SHARES_MIN_SIZE)Gb before all others. FIRST_SHARES_MIN_SIZE
should be specified manually in config to fit all the firs-order hosts to
the first page (so, user will realize that host he interested could be at
the next pages). According to this criteria, FIRST_SHARES_MIN_SIZE could be
not configurable, but selected automatically to select not more than
vfs_items_per_page.

3. Add 'go network' link along with 'go up' link. It should appear at least
at share root pages (it's odd when 'go up' should be pressed twice to go
from share root page to the network's shares list while links at the latter
leads to shares root directly). For "list of host's shares" page it should
appear instead of 'go up' link.
Also, this link could contain host id as parameter (to redirect
automatically into the right sharelist page) or even correct page number
(if this operation doesn't require additional queries, I don't sure it do).

4. Current directories at shares could be shown in vista explorer style
(every folder is link to it). This could be done in different ways though,
because there are no links to the pages higher then single upper level at
vfs, so this links may lead to vfs also. Of course, we could eliminate 'go
up' links and show the full path as links though to vfs and to shares
itself. But, if calculating link to the upper pages require additional
queries, we should just make links to upper levels of share.

5. Also we could add the additional page navigator (may be, lite-version of
the bottom one), but don't sure it's needed

Original issue reported on code.google.com by radist...@gmail.com on 23 Feb 2010 at 11:52

[GoogleCodeExporter]

Addition for proposition 1: we could create table "shareletters" with 3 columns
(letter, network and sharecount) and trigger which will update statistics for 
letters.

Original comment by radist...@gmail.com on 23 Feb 2010 at 12:19

[GoogleCodeExporter]

6. Links with IP addresses for SMB.
Most computers are configured with hostname which doesn't match hostname from 
DNS. It
causes problems with smb protocol: client specifies server's name for logon and
server declines it. If this windows-samba-client-specific, then we should add
hostname resolve to the protocol_prepare def (however, this is inapplicable to 
the
offline hosts).

Original comment by radist...@gmail.com on 23 Feb 2010 at 1:06

[GoogleCodeExporter]

>add hostname resolve to the protocol_prepare
absolutely no since this may cause a huge wait for nothing
if you really want to have liks with ip address instead of a hostname then add 
ip
address column to the shares table and update it with pinger

Original comment by ruslan.savchenko on 23 Feb 2010 at 7:33

[GoogleCodeExporter]

> if you really want to have liks with ip address instead of a hostname then 
add ip
> address column to the shares table and update it with pinger
If DNS is working well, additional DNS caches are meaningless. For networks 
without
DNS it's better to use IP addresses which are resolves quickly enough. Also, 
links on
VFS pages always belong to the one host name, so resolving will be done just 
once.
And finally, we don't need to do this for offline hosts.

Original comment by radist...@gmail.com on 23 Feb 2010 at 7:49

[GoogleCodeExporter]

>VFS pages always belong to the one host name

what about search page? Why don't you care about it?

Original comment by ruslan.savchenko on 23 Feb 2010 at 8:07

[GoogleCodeExporter]

> what about search page? Why don't you care about it?
anyway, user may navigate to the VFS. And let's wait with 6th subclause till 
I'll
gather statistics.

Original comment by radist...@gmail.com on 23 Feb 2010 at 8:40

[GoogleCodeExporter]

Idea 6 moved to issue 42

Original comment by ruslan.savchenko on 11 Mar 2010 at 5:35