This is not a core library approach either, but I think that in chess
open source software they tend to use a similar approach, with a few GUI
applications and many engines using a common communication protocol.
That may be an intresting project for those interested in GUI
programming. A backgammon GUI front-end, with various back-ends to
communicate with gnubg, fibs, dailygammon, another GUI over a chat
application, etc...
Yes! The computer chess community did it right! However they ended up with two different protocols, WinBoard and UCI, which are pretty different.
So, if we plan to make an Engine/GUI separation, we need a good protocol. We have to define such. Even that is challenging.
What should the engine store and what should the GUI store? Should the engine know the state of the board, or should that be transferred over the protocol? Where should the game/match be stored? And what about a rollout? Should the GUI or the engine organize the rollout? And should we be nice with others and base a protocol on something? A REST API? Just not SOAP!
*sigh* These are questions that made me abandon the idea...
-Øystein