[Pan-users] Re: Choosing Your Posting Server (Was: 1.0 or not?)

[Duncan]

"Steve Davies" <address@hidden> posted
address@hidden, excerpted
below, on  Wed, 26 Jul 2006 11:48:11 +0100:

> On 7/25/06, Charles Kerr wrote:
>
>> [Duncan wrote...]
>>
>> > [Suggestion: What about the] posting server a function of the posting
>> > profile?  http://bugzilla.gnome.org/show_bug.cgi?id=348667
>>
>> I agree that this needs to make it into 1.0.
>>
>> Adding it to the posting profile makes sense, except for
>> error-handling:

I was wondering about that too, but decided I had to think about it a bit
before I could suggest anything.  The points below helped resolve the
specifics of the question, but I'm not sure I have a solution as nice as
the first part of the suggestion was.

>> (1) how should Pan handle it when the posting server doesn't have all
>> the groups listed in the new post's Newsgroups: header?
> 
> I assume that the server will inform you of this fact when you send it
> the headers. Basically I say log it and carry on :) If you get the
> opportunity, then perhaps the offering a dialog box to say:

>From what I know of NNTP, bad assumption. =8^(

See, the thing is that it's not entirely uncommon to do that deliberately. 
Not all groups are on all servers (obviously), and it's considered valid
to send to an expanded list of groups, some of which may not be on the
posting server, as when the post propagates to other servers, it'll show
up in all the groups that happen to be on the new server.  Again, that's a
valid and not entirely uncommon reason to post to groups not on a
particular server.

The group list DOES have to include ONE group on the server in question,
however, or the post will be refused.

> 1) Cancel posting entirely
> 2) Continue - Send to reduced list of newsgroups 
> 3) Let me edit the posting again please.

In light of the above, this isn't sufficient.  Probably replace 2/continue
with reduced  list of groups with 2/continue as is.

However, that doesn't seem as intuitive as I know Charles likes to have
it, and it means adding an error dialog, thus forfeiting the bonus below. 
While forfeiting that bonus /might/ be best, I think there's an
alternative.  It's coming together as I write and I'm not fully satisfied
with it, but maybe someone else can brainstorm an improvement.  Anyway,
throwing it out there...

Given the above, that posting to more groups than the server has can't be
assumed invalid...

I'd suggest another go-back/post-anyway warning, similar to those (like
the GNKSA warnings) PAN already has. If we're lucky, Charles can re-use an
existing dialog template so we can squeeze by on the bonus on a
technicality. =8^)

Warning:  The server for the posting profile assigned to this group
doesn't carry all the groups you x-posted to.
                                     Go Back | Post Anyway

Umm... something like that anyway.  The wording isn't quite as intuitively
simple as I'd like, but the idea seems to fit existing PAN warning
solutions, anyway.

To eliminate the most common form of the above, if the server chosen for
the profile doesn't have a group, that profile could be deactivated/hidden
as a choice in the posting server group preferences.  (Unfortunately, due
to the permutation below, plus possible complexity in getting this working
right, this aspect may not be viable.  It's likely simply too complex to
implement in a working bug-free way, without either introducing way
more betas than we want before 1.0, or forcing the feature to 1.1, neither
of which is palatable.)

The next permutation is the problem of what happens if a user switches the
chosen server on a posting profile after building a list of groups using
that profile.  Let's see if there's a sane solution after dealing with the
next issue Charles listed, however.

The back/continue dialog's still reasonable, tho, I think.

>> (2) how should Pan handle it when the user deletes the news server
>> specified as the posting server in the profile?
> 
> New dialog "Sorry, that server is used in...."

Ouch!  Again, that looks like it might be too complex to implement in a
bug-free way in the time available, due to having to scan or keep track of
the information for the "in <profile>" (I assume that's what you implied)
part.

Three-part (but small parts) solution?

a) When implementing the posting-servers portion of posting-profiles,
include what we can call a wildcard entry.  This could be named "pan
chooses", "automatic", "default", "any available", whatever.  The
implementation of that would be what pan's doing now, so it's essentially
"free" in terms of implementation cost.

b) With such a wildcard server entry, the logical (and expected/intuitive,
well, as much as one would think of it in advance) handling in case of
server deletion is to return the profile to the default entry.

c) Maybe a tooltip or warning label to the effect of stating the above, in
the selection?  This isn't quite satisfying yet, but the idea again, that
it would fit with the existing "additional help" solutions.  On the
satisfying thing...  maybe I'm letting the not-perfect be the enemy of the
good?  IOW, perhaps it's not perfect, but I'm not sure there /is/ a fully
satisfactory/perfect answer here, and one has to admit that while it
/isn't/ entirely perfect, it's far better than the current (risky and
unintuitive) solution, and with or without the tooltip/warning, behavior
will be far less risky and far more intuitive than it is today.  Perhaps
that's "good", even if "not perfect".

...

That leaves us with the unfinished business above -- what to do if the
no posting group is on the chosen profile (and the single-group
special-case version of same).

Using the back/continue warning dialog above, is it possible to use the
same template but only show the go back button (hide the post anyway)? 
Perhaps using that and some choice wording and variables, the same warning
dialog can do double-duty as an error dialog, group(s) not on server, go
back (single button)?

>> Bonus points if the answers to these questions don't involve any
>> complicated new GUI pieces. :)
> 
> Like I say, just my 2c. I think the above is reasonably uncomplicated
> which is usually a bonus.

The question of these errors is a tough case.  As I said, I'm not sure
it's possible to get it "perfect".  I'm also not sure if the idea squeezes
into that bonus qualification or not, but at minimum, the suggested
additional dialogs won't be /too/ complicated, two-choice max, and
perhaps a tooltip, and will fit in with pan's existing GUI.

So... more brainstorming absolutely welcome!  If someone comes up with as
"beautifully simple UI" (well, from a user perspective, I'm not sure I
want to ask how complex it might be to implement, but both Charles and I
seem to agree it needs done by 1.0 if possible) a second-half solution as I
think my first-half was, I'll be duly impressed, as I certainly can't, or
at least haven't yet!

I guess another way to look at it is that not so many of the clients that
have implemented automated multi-server do posting at all -- many are
download-only!  That certainly applies to both BNR2 and klibido, AFAIK. 
If these sorts of issues were simple, I'm sure it'd be rather more
commonly implemented.  The fact that it's not says something about the
rather exclusive class of news client that pan now belongs to! =8^)  The
good news is that it doesn't take a perfectly implemented solution to
beat no solution, hands down! =8^)

-- 
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