Clients should support FIBS

[don]

While I applaud both FIBS for opening up to client software and programmers who have provided many options for FIBS' users, I have two general problems with client software:  Most clients fail to make use of FIBS commands and resources while failing to make an obvious bridge to these commands; Some clients emulate FIBS commands internally leaving their FIBS' presence in conflict with the normal telnet interface.

In the first case, how many times have you seen confused new users trying to set a toggle, start a game, almost anything, when a simple reference to the FIBS' help files in the client interface would answer all questions?  Considering the complexity of actually writing a client-GUI, the addition of a simple link on a drop-down menu to FIBS' extensive help files should be simple, for example.  An explanation of how to send commands directly to FIBS should be an obvious and useful utility for new users of these wonderful programs.

In the second case, I think that clients who internally implement FIBS commands such as pip counters should responsibly set FIBS' toggles to reflect their state.  If a client is counting pips for a user, the allowpip toggle should be on in order that opponents can access FIBS' pipcount.  (Indeed, this is probably why the general tournament rule is that the FIBS' toggle should be on, no matter what the internal state of the client.)  If a user is gagged internally by a client, the client should take it upon itself to emulate the FIBS' action to provide what is deemed appropriate feedback or simply use the FIBS' gag command.

--
don

[adrian]

I agree for the third time, in three years, with Don. Smites expected, but who cares. He`s right.

A happy new year for you all fibsroids !   Listen, read, learn. Playing is not enough.



With love, 

[socksey]

I agree also!   

Now, we must convince the programmers.   

socksey



"To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public." - Theodore Roosevelt
 

[diane]

Now, we must convince the programmers.   
 

But don IS convinced - he just cant seem to make a client anyone wants to actually use....now if we could only fix don....

[don]

Although I don't see any relevance to this discussion in diane's reply on this thread, it might be useful to make a couple of points in a Happy New Year way.  I'll leave any comments about actually programming clients to a response to posts like Padski's request [text-fu] where they belong.  Why not declare some kind of a truce where tournaments are concerned?  That would be directly relevant to this topic.

For example:  When playing in a tournament not run by you, you should disable any client-provided gag or blind so that normal play can proceed without involving the TD in what should be normal communications.  In fact, it is particularly in a tournament that your client should act as other clients expect FIBS to act.  All of your client settings should be set to behave as FIBS' I/O is expected to act.

For example:  When running a tournament, you should either disable your clients' internal permagag or invoke FIBS' gag feature so that users who try to enter your tournaments with a requested "tell diane" get the expected response that their request is not going through.

The Happy New Year part is simply that I am suggesting normal and polite and expected FIBS behavior during tournaments, unless they are run by diane, in which case I am requesting at least the normal FIBS' response, if she so chooses.  I think this would erase most arguments between us and possibly save the world!

--
don

[padski]

don,

it would be possible to define an inter-client protocol.

say, for example, "kibitz please"

statements in kibitz please might best be drawn from a specified list of
exact strings formulated for use in circumstances like those you describe.

for example, "kibitz please toggle allowpip", "kibitz please roll"

the command "kibitz please help" could return the usual useful information
about the version of the protocol implemented and the available options
(or in the case of a human operator "what?")

compliant clients would return either an acknowledgement or an error,
being free not to bother their player when the request did not make sense
(allowpip is on, I have already rolled), or implement the request directly
without bothering the player.

compliant clients would notify the TD in some error circumstances, which
could be modulated by an extension to tourneybot, with some reasonable
default for tournaments not implementing/specifying notification options.
The specification of a requirement for perma-gag using clients to implement
kibitz please and possibly also other options (like must play with allowpip on)
could be similarly encoded, as could notification to players regarding sanctions
for abuse of the rules.

an anciliary protocol could be defined for other permitted parties (for example,
TDs, tourneybots) to interrogate the status of kibitz please systems.

clients could implement kibitz please regardless of perma-gagging, so there
need be no leakage of information about the status of the perma-gag
(AFAICS), which after-all seems to be the main feature of that technology.

best of all, the hurdle for implementors would be extremely low, requiring no
more for a basic implementation than that kibitzes begining "please" be allowed
through (let's call this v1 shall we?)

I would be willing to implement something like this if there were interest from
other parties.

would you be willing to help test something like this ?

oh, and best wishes for a Happy New Year 

[don]

Thanks Padski, and Happy New Year to you too!

Your ideas are interesting, but you are talking to the wrong person.  The root of FIBS is the actual programming and the telnet and CLIP protocol.  If you have some clients agreeing with each other, they still won't be agreeing with all clients unless they conform to the root, telnet and CLIP.  There has to be agreement between clients and on FIBS.  The only place to change the basic agreement is FIBS itself.  You are a programmer.  Imagine if a main() had x-amount of functions, libs, procedures, etc.,  all written by other programmers with their own opinion of what main() should be doing!  Even if a majority of them, even all of them, decided to change things, still, changes have to made in main().

I suggest you get a group together with your ideas and persuade FIBS to change the protocols (http://www.fibs.com/fibs_interface.html).  I like many of your ideas!  Until they are changed, FIBS clients should conform to the expected behavior.

--
don

[padski]

Don,

I really can't see what can be done about 'client-side' gagging at the server side, except possibly for implementing it there.

the client takes delivery of the information from the server and the user is free to ignore it if they wish, and I see no difference between using a program and sticking your fingers in your ears and singing 'hey macarena'.

similarly the idea of all clients conforming to a single root is misguided: diversity is the natural and healthy state.
The variety of fibs client implementations bring great value to users, and the users themselves are the main 'police' (although of course it would all fall apart without the admin, who is all too often the un-sung hero).
The fact that fibs.com is only one of an increasing number of implementations is one that you seem also to overlook. The current apparent singularity of fibs is just a local maxima that will inevitably change with time.
And interoperability is about a lot more than conforming to any one person's idea of how things should be.

Please consider the benefits of kibitz please again:

*
* There is not even any need to modify existing clients to support kibitz please.  any existing client which supports a
* client-side only gag can use a trivial helper program to enable it to support kibitz please.
*
* it is not sensible to suggest that such an experiment be carried out on the server-side first.
*
* the technology to support kibitz please is trivial and could be rolled out in a short space of time. 
*
* It only depends on people to implement it.  And this is a proposal that attempts to maximize not only the ease of
* implementation but the chances of getting buy-in on all sides.
*

but if users are unwilling to participate, then I see little point. and it is tempting to conclude that they have no real wish to improve the situation.

fundamentally, it's not about programs, don, it's about people.

but with a little effort from people, don, the programs could be improved ...

Regards,
Paddy

[don]

Paddy, I don't think you are getting my point, tho in fact you are making it for me.

I really can't see what can be done about 'client-side' gagging at the server side, except possibly for implementing it there.

Communications are already defined on the server side, and defined quite adequately IMO, in the FIBS Client Protocol Detailed Specification.  Regarding

it would be possible to define an inter-client protocol.

I don't think it possible.  As you know, many clients in use today will never be changed --  They are not being updated, their programmers no longer use or care about FIBS, .... Your "kibitz please" command requires no modification of client programs except for a "trivial helper program".  This seems like modification to me!  Who is going to write this trivial program?

When I learned programming I learned the need of a central and consistent control of every project, such as main() with functions foodon() and foopadski(), in which case foodon() and foopadski() had better use the same communications' protocols.  The response from main() should convey the same meaning to each function.

      _________
     |         >-----< client don
     |  FIBS   |
     |_________>-----< client padski

All FIBS' communications are clearly defined in the protocol as well as in the help files.  Until these are changed, Paddy, when FIBS informs client don that client padski has received a communication, it should be so.  Now I Peter (cthulhu) Nevalainen had any intention of violating this protocol when he wrote JavaFIBS.  I certainly can't criticize the wonderful extra features his (and others') clients implement to add to the experience of using FIBS.  But I do believe they should make those features function, as I've said, so that users of other clients get the expected behavior while using FIBS commands.

As a challenge, why don't you write your simple helper program for JavaFIBS so that when I am not communicating with it, I get the expected response?  Simpler to have it respond to any kibitz that it is ignoring on behalf of its user with a "tell don (or whoever) your kibitz is blocked", then try to run through your "kibitz please whatever" suggestion.  Simpler to actually "gag don (or whoever)", as well as render any wonderful features it wants for its user.  I don't believe you've thought this through.

In the meanwhile, I suggest that it would be courteous for users who are involved in tournaments, and particularly responsible and experienced users who are running tournaments, to disable such features of their GUIs when running a tournament on FIBS or playing in a tournament with a FIBSter who might expect some reasonable communication such as FIBS provides according to its internal help and the above cited protocol.

Hey Macarena!

--
don

[padski]

Don,

The FIBS protocol requires CLIP clients to do their own client-side filtering to implement a gag.

JavaFIBS already implements the facilities for players to use the fibs gag. There is no helper program required for this.

Granted that if it does not do so already it might be nice if it had distinct options for 'gag' (client & server) and 'ignore' (client only).  But then you have options for temporary or permanent, and other related options like blinding.  It is easy to see why a gui author would steer clear of providing an excess of options.

But as you already know, there are players who gag you don, who understand how to use this facility and actively *choose* not to.

Indeed, CLIP, being the later addition, would seem to be an acknowledgement that the fibs server gag facility is in fact a convenience for text clients: not a necessary part of the server, but a bit of client built into the server, much like some board-styles.  I wouldn't get hung up on the exact form of one particular client if I were you don.

We have already established that we have differing views on the relationships between programs, protocols and interfaces.  In my experience, such philosophies are formed from a wealth of experiences, and are not always easily communicated, so it would sensible not to labour the point at this juncture, although I would welcome the chance to discuss this with you at length.

I think it is entirely understandable why the gag feature exists, both in the command-line and in clients. You don't have to be on fibs long before you see the likes of bgfd.

I think that the work that TDs do to enable difficult players to play in tournaments is extremely admirable.

It is a pity, but not entirely surprising, that the situation seems to be beyond technical help, but I do thank you for taking the time to consider my suggestion, and I look forward to future conversations with you.

Regards,
Paddy

[don]

Paddy:

re:

The FIBS protocol requires CLIP clients to do their own client-side filtering to implement a gag.

The protocol does not require the client to do any client-side filtering to implement the gag.  Also, to issue a permagag-like feature, all a client has to do is detect logins (as JavaFIBS does).  I'm only saying that if a client does decide to do its own filtering, it should produce the same results for users of other clients as does FIBS.

We have established that either you don't understand what I'm talking about or are being purposely obtuse.  Until you can figure it out, as have most of the other readers of this thread (including adrian, socksey and diane), we have not established any disagreement.

Hey Macarena!
--
don

[burper]

Your use of the word "we" is a bit sanctimoneous, is it not? I don't believe "we" have "established" anything of the kind, and you presuming to speak for everyone could be mildly offensive to some. I know you don't mean to be anything but provoking however.

I'm only saying that if a client does decide to do its own filtering, it should produce the same results for users of other clients as does FIBS.

Why?

Assuming you are gagging someone for a reason, and assuming that reason is generally because they were wasting your time or being offensive to you, isn't it better that you waste their time by allowing them the illusion they might be heard? What is it you owe them? Courtesy?
A bit more practical, it reduces the chance they attempt to side-step the gag by re-logins.

I agree, in the corner case where you are gagging somone and also wish to be courteous toward them, that it would be nice to optionally let them know they have been gagged, but I would not go so far as to say *should*. Besides, you can always use a tell just before the gag to accomplish this.

Any client-side functionality can be added to existing client software via the use of a local proxy, including the implementation of a client-to-client protocol. I have implemented such a local proxy. Twice. The first one was called FibsCompanion (http://fibscompanion.sourceforge.net/). I haven't released the newer one as yet.

I also dont think you would have to change fibs. One could "wrap" fibs. In fact, ParlorPlay is an example of this. Users don't use anything like telnet or clip to communicate and play on fibs.

Another example of changing fibs is the various ways people run touries without tourneybot. Yes, I believe they are mostly implemented with carbon-based processors with lead/pulp back-ends, but they could be implemented as a customized tourneybot-ish program.

Another example of how fibs might appear different to me than you, is if I gag padski and you don't (using the fibs mechanism). Now you see padskis' shouts and I do not. Our clients are now not getting the same "expected behaviour". In effect, we have "programmed" our two protocols differently. Would you argue that the gag feature should not be implemented in fibs?

I don't buy your argument that every client needs to be in 100% agreement. Would you argue that because my client does not support the 'raccoon' command, that it should not be allowed on fibs, even though noone "ever" uses it? On the internet, noone knows your client is a dog If your cient wasn't able to generate the 'join' command, and I kept inviting you and getting no response, I would just give up and invite someone else.

I haven't read this thread in detail, so forgive me if I missed this, but is there a concrete example of where tourney opponents must not be gagged? I would say it is an issue only for the TD, and i they have no rule, then the participants. If I want to join a tourney, and the TD has no such rule, but I see that MrOffensive has also joined, should I leave the tourney? Ungag them when I play? I there a particular need to "be polite" to someone I find offensive when paired in a tourney match?

Note: of the people that agreed with you, I know that socksey would not consider herself a programmer (she implies it in her response), I'm pretty sure diane is only a programmer to the extent she lives with one, and I am pretty sure adrian is not either. Of the two people that disagree with you, both consider themselves as programmers. Although, I would never go so far as to say I am smarter than the all-knowing don.

[don]

Thanks for the reply, burper.  You make my case when you say,

I haven't read this thread in detail,

so let me know when you want to have a serious discussion.

--
don

[diane]

I know you don't mean to be anything but provoking however.

Of course he does...


Assuming you are gagging someone for a reason, and assuming that reason is generally because they were wasting your time or being offensive to you, isn't it better that you waste their time by allowing them the illusion they might be heard? What is it you owe them? Courtesy?

Exactly - I owe that twerp nothing


I agree, in the corner case where you are gagging somone and also wish to be courteous toward them, that it would be nice to optionally let them know they have been gagged, but I would not go so far as to say *should*. Besides, you can always use a tell just before the gag to accomplish this.

He has been repeatedly told - he can see my shouts for instance - he would have to have his head in a bucket for the last few months to not know this....


I haven't read this thread in detail, so forgive me if I missed this,

Note: of the people that agreed with you, I'm pretty sure diane is only a programmer to the extent she lives with one,

Arghhhh - surely even without reading this YOU would know better than that!!  He just wanted me back in the thread- thanks!!

Anyhoo, enough of all this posting - just look at all those tasks don has set for padski - gosh I guess I will be doing all the dog walking now - and I expect his business clients will be understanding when he misses meetings and deadlines cos he is doing dons bidding 

[don]

Arghhhh - surely even without reading this YOU would know better than that!!  He just wanted me back in the thread- thanks!!

I'm sorry, I really don't understand this.  I don't think burper and diane are contributing to this thread and are trying to change the topic, if not flame.  I'd suggest they both take the time to read and understand before they reply.

--
don

[don]

In fact, though I chose to ignore it, diane's only other contribution to this thread,

But don IS convinced - he just cant seem to make a client anyone wants to actually use....now if we could only fix don....

was really a flame.  I'd appreciate it if diane and burper would create their own thread to flame me, so that a discussion can continue.

--
don

[don]

In fact, here's diane making another point for me.

He has been repeatedly told - he can see my shouts for instance - he would have to have his head in a bucket for the last few months to not know this....

Can I see her shouts?  How does she know this?  She is assuming this because she expects clients other than the one she is using to conform to the FIBS protocol.

--
don

[don]

Hey Paddy.

I thought we were having an interesting discussion and I'd like to continue it, skipping the posts from diane and burper.  The topic is:  Should FIBS clients conform to the FIBS protocol?

--
don

[diane]

Firstly to reply to the actual content of this thread - in burpers thread he states

Of the two people that disagree with you

Make that three - aside from the fact that if don said the sky was blue I would start to see it as more orangey - there is no need for all clients to tell don he is gagged.  I am sure I am gagged by some out there - and it affects my life not one jot whether I know this or not.  I have neither time nor inclination to chase those who don't want anything to do with me - shame don cant see it that way too.

Next - I wouldn't expect any removal of flames from this board - we have seen over and over that that isn't going to happen - you can flame, don, and do - as can anyone else.  The management learned a long time ago what sells newspapers and that advertisers prefer to pay for space in a popular newspaper than one with integrity.  don, you drag my name into almost every post you make hoping to get me contributing - and I am sure fibsboard management see it just the same way. They also learned there is pretty much only way to get fibsters involved and that is to make an argument - they aren't much interested in technical discussions,  or feature improvements, but a good burper, diane, don row can fill page after page after page - do you begin to see why I am pulling myself out of this? 

You discuss what protocols clients should / should not have by all means - but do try to leave my name out of it - I am far too busy to even read this thing more than once a fortnight or so.

While you are issuing padski with instructions

As a challenge, why don't you write your simple helper program for JavaFIBS so that when I am not communicating with it, I get the expected response?

,

I suggest you get a group together with your ideas and persuade FIBS to change the protocols

,

Who is going to write this trivial program? (implying not don of course)

, maybe you could consider helping, instead of sitting there arguing all day with whoever will take the bait in shouts - haven't you anything better to do??  Padski has plenty of other things to do - and still is managing to find time to actually put a new client together, and these long 'interesting' discussions take his time away from that.

Help don - other than by criticism - or butt out and stop whining, gosh I seem to have heard that soooo many times before.

[padski]

The FIBS protocol requires CLIP clients to do their own client-side filtering to implement a gag.

The protocol does not require the client to do any client-side filtering to implement the gag. 

Don,

do you mean to disagree with my statement?

or are you simply stating that clients are not absolutely obliged to use the CLIP protocol that was designed and implemented specifically for the purpose ?

Regards,
Paddy