News:

we welcome new Sponsors..keep the board going.....advertise your thing for a modest donation contact the webmaster@fibsboard.com

Main Menu

Clients should support FIBS

Started by don, December 16, 2006, 06:30:55 AM

Previous topic - Next topic

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
So many string dimensions, so little space time...

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.

:rules:

With love,  :veryhappy:
Helping people is tricky. Give help to anyone and he will remember it only when he is in need again.

socksey

I agree also!   :yes:

Now, we must convince the programmers.   :unsure:

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

Quote from: socksey on December 30, 2006, 12:25:28 AM

Now, we must convince the programmers.   :unsure:
 

But don IS convinced - he just cant seem to make a client anyone wants to actually use....now if we could only fix don.... ;)
Never give up on the things that make you smile

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
So many string dimensions, so little space time...

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
So many string dimensions, so little space time...

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.
QuoteI 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
Quoteit 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
So many string dimensions, so little space time...

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:
QuoteThe 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
So many string dimensions, so little space time...

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.

Quote
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,
QuoteI haven't read this thread in detail,
so let me know when you want to have a serious discussion.

--
don
So many string dimensions, so little space time...

diane

Quote from: burper on January 07, 2007, 12:57:03 AM
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  ;)


Never give up on the things that make you smile

don

Quote from: diane on January 07, 2007, 09:49:35 AM
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
So many string dimensions, so little space time...

don

In fact, though I chose to ignore it, diane's only other contribution to this thread,
Quote from: diane on December 30, 2006, 06:26:43 AM
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
So many string dimensions, so little space time...

don

In fact, here's diane making another point for me.
Quote from: diane on January 07, 2007, 09:49:35 AM
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
So many string dimensions, so little space time...

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
So many string dimensions, so little space time...

diane

Firstly to reply to the actual content of this thread - in burpers thread he states
QuoteOf 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
QuoteAs 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?
,
QuoteI suggest you get a group together with your ideas and persuade FIBS to change the protocols
,
QuoteWho 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.
Never give up on the things that make you smile

padski

Quote from: don on January 06, 2007, 05:25:10 PM
Quote from: padski on January 06, 2007, 12:53:12 PM
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

don

Paddy,
Quote from: padski on January 07, 2007, 01:06:55 PMdo 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 ?
Yes I disagree with your statement.  The protocol does not require the client to do any client-side filtering to implement the gag.  To elaborate, all a client has to do is issue a gag command, and this command can easily be sent to FIBS every time the offensive user logs in.  If the client does the filtering then it should be responsible for FIBS-like behavior and responses.

I can't quite figure out what you are saying in your OR clause so I don't know if I agree or disagree.  You have it phrased somewhat like a "have you stopped beating women?" question, and I don't want to touch it.

So that's a clear answer to a clear question and a dodge of a vague question.  IMO, a programmer should be able to phrase a question clearly, if he's interested in a discussion.  Have you stopped beating women, Paddy?  See?  There's no yes or no answer.

--
don

PS -- I'm ignoring diane's post because I can't see any relevance to this topic in it, except as she provides examples of the behavior I'm talking about.  I am not objecting in this discussion to users like diane, zyxtcba, donzaemon and others who hide and snipe behind gag.  That's not a client issue of great concern here.  It only becomes a serious client issue when I'm forced to interact with them in situations like tournaments and I don't get the well-designed feedback specified by FIBS.
So many string dimensions, so little space time...

burper

Quote from: padski on January 07, 2007, 01:06:55 PM
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

I think what don means, is that your client could use the fibs 'gag' command instead of any client-side filtering.

This means monitoring when users log in and re-issueing the gag, and probably the blind, either manually or programmatically.

Someone could still issue invites. If the client-side filtering implementation included invites, but was still name-based, one could create new nicks to do the inviting with, such as INoUHearMeAHole. One could write a script to automate this to get multiple "messages" through. don, write this script.

So I read and understand the whole thread in detail and stand by everything I posted previously, and meant it all seriously. So don, any reply other than sticking your fingers in your ears and singing "LA LA LA LA LA I'm not listening" loudly?


burper

Quote from: don on January 07, 2007, 11:39:21 AM
The topic is:  Should FIBS clients conform to the FIBS protocol?

Absolutely not.

Can you name any client that conforms 100% to the protocol for which it is being used?
First question when you find one: which version or the protocol?

burper

Another example relavent to this discussion: those mobile phone fibs clients.
They typically do not implement shouts, in order to conserve both bandwidth and screen space.
In what way is this different from using client-side filtering (with no automated reply) in place of gag?

burper

Quote from: don on January 07, 2007, 02:22:36 PM
Quote
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 ?
I can't quite figure out what you are saying in your OR clause so I don't know if I agree or disagree.  You have it phrased somewhat like a "have you stopped beating women?" question, and I don't want to touch it.
I don't think this is a "beating your wife" question at all. I think you answered it by saying you thought it was ;)
I would agree with that statement. Clients are free to bypass the use of CLIP. Anyone who uses telnet or tinyfugue knows this. One *could* implement a gui approximately like javafibs using straight telnet. You might question that persons sanity, but that would be a different question.

burper

Another point here, since "we" are talking about conformance, I believe the only specification that could be considered official here, is the one written by marvin back in 1997.

If you wanted to "do the right thing" and be 100% conforment, you should ignore the greatly expanded later version, which is unauthorized. You should also ignore FCM, as that takes great liberties with the official spec, and apparently was implemented by "reverse-engineering" much of the protocol. You would end up with a grossly inferior client from a functional point of view, but it would be 100% conformant.

padski

Quote from: don on January 07, 2007, 02:22:36 PM
Paddy, Yes I disagree with your statement.  The protocol does not require the client to do any client-side filtering to implement the gag.  To elaborate, all a client has to do is issue a gag command, and this command can easily be sent to FIBS every time the offensive user logs in.

When I login non-CLIP and gag a player I no longer see shouts from that player.

When I login CLIP and gag a player, I continue to see shouts from that player.

The single most common use-case for the gag must surely be to deal with the likes of bgfd the other day.

A CLIP client has to filter on the client-side, to implement the same gag that a 'telnet-client' gets.
Indeed to get what is in practice the most basic gag function.

At least, such are my recent observations, but I am very new to this.  I had thought that such an interesting wrinkle would be well known, and that my statement would not be controversial.  Hence my pains to ensure that this is indeed a point of disagreement and not merely a misunderstanding on my part ?

Is there something that I have overlooked ?

Although it may simply be a case of simplifying something that was previously overengineered, it would come as
no surprise to me to discover that this change is in fact intended to address a weakness in the original fibs gag.

but this is just one detail in fairly complex picture, which anyone could easily stumble over, and yet I fear it could take some considerable time to go through it all in this level of detail.

Don,  you've pointed out a real hole in the existing system. I think we are fortunate that it has come to everyone's attention before it could be exploited by mischief makers intent only on causing trouble.  I am sure the players and TDs will join me in applauding you for cutting straight to the heart of the matter in identifying a lack of decorum.

I have great sympathy for the general view that gui authors should be encourged not break to underlying text interfaces, but for the reasons I have outlined strongly disagree with your contention that this is what is happenning in this case.

I would encourage you to set aside your impractical insistence on the legacy fibs gag and focus instead on looking for real practical solutions to a problem which is essentially non-technical.  As I have pointed out the technical community may well be able to offer some asssistance.

The please kibitz proposal has the considerable benefit of addressing the immediate problem directly and specifically, whereas the impact of the fibs gag is much more pervasive, even if it is at first sight elegant, and has the considerable disadvantage of already having a history. Although I do not have any stories to hand, it would not surprise me discover that there are already known weaknesses in the fibs gag that make it unsuitable for the purpose you propose.

Sadly, neither of us has a role in this that adds to the credibility of our genuinely intended proposals, and so it will be a loss if we reach an impasse on some fine point of technical principle, without exploring the various practical possibilities.  I have gone to considerable lengths to explain the reasons why your proposal will not work, and I would be grateful if you take a little time to point out possible problems with please kibitz.

Regards,
Paddy

don

Hey Paddy.

Happily there is a simple solution to the major problem, that of participants in tourneys whose clients aren't exactly on spec:  Participants and TDs should be encouraged, if not required to temporarily disable those features of their GUIs that don't conform.  This would amount to disabling permagag, any auto-blind function, and setting toggle-allowpip to on.  If an offending user harasses during a tournament, then it is up to the tournament director to handle matters -- an improvement on the current situation where TDs can be hassled handling what should be routine communications between players.

--
don
So many string dimensions, so little space time...

padski

Don,

I hope you will come to see that badmouthing the authors of clients and their users and pressuring TDs to take sides does nothing to advance the cause of improving the atmosphere.

I know from personal experience playing you with a client that really did have a problem that you were entirely gracious about it, and that overall players on fibs are both extremely friendly and understanding.  It would be a shame if people were to get a wrong impression of fibs from the quarrels that sometimes spill out onto the web.

In the end, while I sincerely wish that we could all just get along amiably, I have to find the grace to accept that sometimes things are the way they are for a good reason.  I can only hope that you can too.

I do thank you for engaging in discussion on this matter, and I hope you will understand me taking my leave of it now, if you have nothing further to add.

Regards,
Paddy

don

Hey Paddy.
Quote from: padski on January 08, 2007, 08:51:22 AMI hope you will come to see that badmouthing the authors of clients and their users and pressuring TDs to take sides does nothing to advance the cause of improving the atmosphere.
I agree that badmouthing the authors of clients and pressuring TDs to take sides does nothing to advance any cause.  I don't know why you point out something so obvious.  Has somebody been badmouthing authors and pressuring TDs?

I hope you will come to see that beating women is wrong, Paddy.

Cheers!

--
don
So many string dimensions, so little space time...

adrian

Ok, even if don will ever be, technically speaking, right again, just disregard my approval for him. Keep them coming:   postcards, brownies and homemade beer, along with smites. It is a great ARENA !  Free to play and free to observe.
( Why couldn't I just STFU  ?? )
:oops:
and
;)
Helping people is tricky. Give help to anyone and he will remember it only when he is in need again.