jIBS as a clone of FIBS

[aleucht]

Hi,

I'm currently devloping an open-source clone of FIBS, which is named jIBS, written in Java and comes with full source code, as some you might be aware of.

To see the current status of that project, you should have a look at JIBS project page, where you also can download the latest release. The latest version is 0.4.0_20 which let you play matches after registering with the server.
Many commands need to be implemented though. But rating changes are now computed correctly and stored in the database. You coukd have a look at the source code to verify that.

To get automatic information of updates, you should register/subscribe the mailing list at jIBS mailing list.
There is also a forum to discuss issues with the jIBS-community. To do that, you post a message to all the list members by sending email to <fibs-develop@lists.sourceforge.net>.
If you like to join the team and assist in developing jIBS, you should simply register as a user at sourceforge, drop me a note , I will you add as a member of the team and greatly appreciate it very much!

Regards,

aleucht@users.sourceforge.net

[snowflakes]

No thanks

[NIHILIST]

Pass


NIHI

[don]

Hey aleucht,

It's a programming challange to duplicate FIBS, let alone improve on it.  It's a lot of work and I've only seen in done once before with any measure of success.

Good luck!

--
don

[fergy]

Creating a clone of FIBS is a pointless exercise. If your goal is to maintain compatibility with existing client apps, you will be severely limited in what you can do to improve the user experience. Moreover, you'll find that replicating all the nuances of the server--and every client app depends on different combinations of those nuances--to be a nightmare task.

Unless a new server offers clear advantages to users, there is absolutely no incentive for users to switch. If you are unhappy with FIBS, go create SOMETHING BETTER, not just a "me too" implementation of decade old software.

[gammboy]

If your goal is to maintain compatibility with existing client apps, you will be severely limited in what you can do to improve the user experience. Moreover, you'll find that replicating all the nuances of the server--and every client app depends on different combinations of those nuances--to be a nightmare task.

You're kidding, right?  The fibs client language (that all clients use), and its nuances are well documented. Part of the specification is that the client specify what version of the language it expects upon login.  This means the current language could be a starting point and enhancements could be easily added without danger of breaking existing clients.

Unless a new server offers clear advantages to users, there is absolutely no incentive for users to switch. If you are unhappy with FIBS, go create SOMETHING BETTER, not just a "me too" implementation of decade old software

I don't think the value or intent is to replace fibs and entice people to convert.  I think the real value of a project like this is having a fallback in the event that Marvin and Patty will finally get sick of putting up with our crap and shut the server down.   It is well known that no one is ever going to get the source code for the existing server, so creating a clone makes sense as long as its both backwards compatible and can be enhanced with new features.  The published CLIPS specification makes the former easy, and the open source nature of this project ensures the latter.

GB

[gammboy]

Hmmm  wonder why my quotes didn't work?  :-/

[diane]

Hmmm  wonder why my quotes didn't work?  :-/

Not sure about the first one, but the second set are definately backwards! It is a bit tricky to get them to work properly - takes me a few goes normally!

[socksey]

Hmmm wonder why my quotes didn't work? :-/

If you have a problem with any posts, you can send me an email and I can usually fix.  If I can't fix it, webrunner surely can, but I probably have more time especially since the new baby has arrived at webbie's house.  

Diane was right about the second quote you tried to make.  The second "QUOTE" is denoted with a * appearing on the button, and should only be used at the end of the quote.

When using quotes, click on "QUOTE" button before the quote with no spaces and again at end of quote with no spaces.  Maybe this was problem.  I'm not sure, but your post is fixed now.    

socksey



The hardest years in life are those between ten and seventy. - Helen Hayes (at 73)

[fergy]

You're kidding, right?Ã,  The fibs client language (that all clients use), and its nuances are well documented. Part of the specification is that the client specify what version of the language it expects upon login.

You're right, I'd forgotten what an excellent job Evan McLean had done documenting the protocol. Even so, there is a significant task to develop a server that will work with existing client software. I remember how long it took Lou Poppler to get NOBS working, and he was constantly encountering compatibility issues with various clients apps (and there were considerably fewer of them back then).

I don't think the value or intent is to replace fibs and entice people to convert.Ã,  I think the real value of a project like this is having a fallback in the event that Marvin and Patty will finally get sick of putting up with our crap and shut the server down.Ã, Ã,  It is well known that no one is ever going to get the source code for the existing server, so creating a clone makes sense as long as its both backwards compatible and can be enhanced with new features.Ã,  The published CLIPS specification makes the former easy, and the open source nature of this project ensures the latter.

I've seen many FIBS-clone projects come and go over the years, and have been frustrated by the over emphasis on trying to be FIBS compatible at the expense of doing something new. FIBS was a reasonable design for its time, but that time is long past. Backwards compatibility is a heavy anchor and severely constricts the ability to innovate.

To base a project on nothing more than "in the event that Marvin and Patti [...] shut the server down" is neither compelling nor interesting. I'd much rather see someone step forward with a vision that would someday allow FIBS to retire with dignity--because something better took its place.

[socksey]

FIBS was a reasonable design for its time, but that time is long past.

I disagree.  I can find nowhere in cyberspace that tops Fibs, as yet.  Indeed, nothing comes close!

Long live Fibs!

socksey



Every time I close the door on reality, it comes in through the windows. - Jennifer Unlimited

[diane]

I disagree.  I can find nowhere in cyberspace that tops Fibs, as yet.  Indeed, nothing comes close!

The point is that the design is outdated - there is no way to retrieve passwords, there is no way to improve that annoying playerlist bug which means you cant see all of the players all of the time... I could go on - but it is all documented here somewhere !

The spirit of FIBS is of course better than anywhere else (well mostly ) - and is what keeps people here - despite dropper problems and technical shortcomings etc.

The idea of rebuilding FIBS would be to improve those technical aspects - and allow flexibilty to be built in, but to maintain the spirit of it.  

There are also many long discussions about whether that can be achieved - I know what I think  

[adamosad]

Well I think that even a clone project is a very good start. Maybe you can find ways to improve it in the future after you finish the current job.

Few people do care to create new backgammon projects these days. I think that anyone who works in a backgammon project is a great person. All of us sit in a chair and wait for a new better server or project that maximizes our utility and we ignore that some "heroes" did the entire job for us. Keep doing the good work!!!  

[don]

What playerlist bug?  Are you referring to a but in a client?

[diane]

What playerlist bug?  Are you referring to a but in a client?

This one..

playerlist bug

[don]

So Diane, you are referring to a problem that a client has with FIBS, something that can be easilly handled via a basic FIBS' telnet interface.

Let me repeat, you are referring to a problem that a CLIENT has with FIBS.

Is there some way I can state that there's no problem with FIBS, but only with the behavior of a client that you want FIBS to fix?  Hmm, Perhaps if I simply said there's no problem with FIBS but there IS a problem with a client's behavior -- and people are blaming it on FIBS.

There are many clients out there that fail to adequately interface with FIBS, and many users out there who blame FIBS for their clients' problems.

[diane]

<Sigh> How did I know that was coming.....

The problem is that FIBS is only compatible with VERY outdated interfaces - ie telnetting.  The future consists of better clients which are easier for everyone to use - especially non typist, non computer programmers like myself - even those with very long fingernails.  

I realise you would prefer we were all still communicating by smoke signal, which was very effective in its day - but the rest of the world moves on - and it would be nice to see something as lovable as FIBS moving forward with it. I would like to see future generations sharing the fun we have had, even when the keyboard has become completely obsolete.

If you feel you can easily write an interface which can offer this compatability and flexibility with the existing FIBS software - I eagerly await that client - and will prioritise familiarising myself with it.  If you could also address the many other issues - such as password retreival etc - we would all be over the moon.

Thx for your input Don - it is always constructive.

[Chris]

It's not a client thing, it's a bug in fibs.
See here: http://www.fibsboard.com/index.php?showtopic=857

[fergy]

So Diane, you are referring to a problem that a client has with FIBS, something that can be easilly handled via a basic FIBS' telnet interface.

Let me repeat, you are referring to a problem that a CLIENT has with FIBS.

Is there some way I can state that there's no problem with FIBS, but only with the behavior of a client that you want FIBS to fix?  Hmm, Perhaps if I simply said there's no problem with FIBS but there IS a problem with a client's behavior -- and people are blaming it on FIBS.

There are many clients out there that fail to adequately interface with FIBS, and many users out there who blame FIBS for their clients' problems.

The FIBS server imposes a hard limit (around 140, if I recall correctly) of how much player info it will send on login or in response to a 'who' or 'rawwho' command. If more than that number are currently logged in, the client doesn't receive full information about who is currently logged in.

This isn't a problem if there are fewer than 140 players logged in. If FIBS had become wildly popular, it would become a more serious issue, but since FIBS user population has remained stagnant for many years, it hasn't been a serious problem.

Clients have adopted different strategies for dealing with this problem, usually by looking for messages from users who aren't in the initial list and then assuming that was a "missing" user and explicitly requesting info about that newly discovered user. Until that happens, however, the client has no knowledge about these missing users, so it is possible for someone to remain missing indefinitely. Hence, you may never know your friend is logged in unless he sends you a chat message, an invite, or otherwise make his presence known.

And finally, I'd point out that the only interface to FIBS is telnet. There are two variants (original and CLIP), but both suffer from this flaw. It is NOT a client problem, it is clearly a server design flaw. I and others raised this issue many years ago, but as with other server problems it was ignored by Andreas, and will likely never be fixed.

[gammboy]

Clients have adopted different strategies for dealing with this problem, usually by looking for messages from users who aren't in the initial list and then assuming that was a "missing" user and explicitly requesting info about that newly discovered user. Until that happens, however, the client has no knowledge about these missing users, so it is possible for someone to remain missing indefinitely. Hence, you may never know your friend is logged in unless he sends you a chat message, an invite, or otherwise make his presence known.

Well, yes and no.  Whenever a user's status changes (goes from 'ready' to 'playing', for instance) fibs sends a CLIPs message (#5 if memory serves) reflecting that change. The client should then update the player list.   This CLIPs message #5 contains all the user info, so the client doesn't have to request any more.

All the client has to do is to recognise the message and add the user to the list if he isn't already there.  The only time a player would remain missing indefinately is if his status never changes, for instance if he is just there to read shouts, or watch a match, etc.

Clearly, this is a server-side issue.  And there is no way for the client to overcome it.  I suppose a client could allow you to maintain a buddy list that it explicitly queries FIBS about, so they would show up regardless of the userlist bug.  Otherwise, it would, as you suggested, have to constantly compare the userlist to shouts and the watcher list to be complete.  And even then, a player that is "away" could remain incognito until their connection timed out.

GB