[Pan-users] Re: Aggregating servers (was Re: choosing news server)

[Duncan]

"Charles Kerr" <address@hidden> posted
address@hidden, excerpted
below, on  Tue, 04 Jul 2006 19:51:07 -0500:

> For a better fix, I like Walt's "disable server" toggle idea.
> It would be in the server edit dialog.  Pan could also show a
> "do you want to disable server?" dialog when it's unable to connect.
> Walt, David, does this sound right?

I like this idea! =8^)

> Anyway, the idea of having an 'active' server a la 0.14
> is a nonstarter IMO as it conflicts with multiserver downloads.
> I'm happy to hear about specific problems and fixing them with
> refinements to the current scheme, though.

The biggest problem ATM is lack of group level state, IMO.  One of the
first things for 1.1 should be yougetting that back.  I'm not sure how you
envision it, but I envision a "group properties" dialog much like the
server or profile properties.  Some group state, stuff like the filter
toggles, wouldn't be displayed altho it would be tracked, as it should be
obvious.  (Alternatively, put that on a tab, showing everything tracked,
for consistency.)  

However, stuff like default posting profile SHOULD go in group properties.
(This should I believe solve the obviousness problem with the former
method, that you had mentioned to me.)  Combine that with an addition to
the posting profile choosing which server to use when posting using it,
and that neatly solves the which server to post to question as well -- in
a pretty intuitive manner IMO.  (Note that if this is done, a posting
profile set to post to a particular server would need to be disabled for
any groups not carried on that server.)

The default save location should also go in group properties, solving
/that/ problem.

Partially solving the problem of the topic, tho I'm not sure of the best
way to set up the group properties interface for it, would be what servers
to poll for a particular group.  The best I've come up with is a separate
tab on group properties, with checkboxes for each server.  Unchecked, that
server will be ignored when polling that group.  Checked, it'll be used if
the group exists on that server.  (Optionally if you or someone wants to
program it, servers where the group didn't exist would be disabled, but
that's not required.)  By default all servers would be checked, of course,
yielding the current behavior.  The server properties activation option we
are considering now would then become a sort of global option, to the
group-local option this proposes.

Another group property could be whether to include it when "download
headers for all groups" is done.  This way, a group could be deactivated
for awhile, not updating unless group update is chosen for that group. then
reactivated when desired, without having to unsubscribe/resubscribe.

As I said, group state retention is IMO the biggest thing still lacking,
so should be top priority for 1.1.  Another "big" feature in old-pan still
missing from new pan is customized hotkeys (I'd love to see that
before 1.0, but don't know how big a project it'll be or whether it would
be destabilizing).  Still another is group categories.  In old-pan, as
you can see from this thread, group categorization was often achieved by
setting up multiple servers, one for each category.  (In fact, I
distinctly remember suggesting that as a solution, to a number of folks
wanting categories.)  Obviously, without the concept of an active server,
that won't work for new-pan, so before too long, group categories/folders
are going to be a must.



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman