On Wed, 2008-03-26 at 22:37 +0100, Zbyszek Skowron wrote: > Hi > > I want to make a native Windows client for TP, as a SoC entry. > The main focus of this client would be to provide client-side rulset > extensions.
I'm afraid that a native Windows only client is not high on our priority list. We already have two cross platform clients which support windows so dedicating effort to one platform is not a good use of our resources. > It is quite obvious, that some activities cannot be carried out on the > server. Building designs (which can be specified on the client with > TPCL, as I've read) is a good example of a client-side, ruleset > dependent activity: > - it has to be responsive, > - there's no reason why it should be done on the server, slowing it > and the network down. The protocol already supports (and so does tpclient-pywx) creating designs locally. It's the whole point of having TPCL. > As I've read about TPCL that it's a Scheme-based language. Funny thing > is that on your web site it's described sometimes as easy to learn, > and sometimes as hard to learn. From my own experience I know that > Scheme is not a user-friendly language. Also it has non-intuitive and > unfamiliar syntax and features. It's a bad choice for client-side > scripts. I'm afraid insulting our choices it not a great way to make a good proposal. We only use a very small subset of scheme and a user should never seen the code. As well we have tpruledev which should make it much easier for people to develop scheme code. Scheme was chosen because it is *very* cross platform. There are native implementation under every other language under the sun. It is also trivially easy to "sandbox". Doing something like designing our own language would just mean that everyone has to implement a new language and no other existing language fits this bill. > My proposal is to identify elements that exist in the interface > (StarMap, Orders, Messages, menus, etc.) and provide means to specify > "overlays" for those, that would modify them in a context dependent > manner. It would be similar to overlays in the NetBeans Platform or > Firefox extensions. Those overlays would be specified declaratively > for both simplicity and ease of use. > > An example would be an overlay for the context menu on the StarMap > used when a fleet is selected. It would add elements that would > generate orders: > > <overlay target="StarMap/Star/ContextMenu"> > <menuitem title="Move" action="addMoveOrder()"/> > <menuitem title="Colonize" action="addColonizeOrder()"/> > </overlay> > > <overlay target="StarMap/Fleet/ContextMenu"> > <menuitem title="Follow" action="addFollowOrder()"/> > <menuitem title="Attack" action="addAttackOrder()"/> > </overlay> tpclient-pywx can already do this in 0.3.1, it does this by detecting the various parameters that orders have. This will get better when we support 0.4.0 as there is more information about what is a valid target. > Similar overlays would be useful in other parts of the UI. > > The overlay mechanism would be somewhat useful on it's own, but what's > really needed to enrich the user experience and allow for interfaces > customised for particular rulesets is a standard scripting language. > As I understand TPCL was designed to help with that, but it's really a > bad choice: > - like said before: non-intuitive and unfamiliar, > - non-standard across different platforms. > > What is needed is a scripting language that could be easily > incorporated into clients written for all platforms, without the need > for implementing it yourself, and one that has a large community > (support, examples, tutorials etc.). > Since TP is already connected with Python, Python would be a natural choice. Actually python is totally the wrong choice, - Python is *impossible* to sandbox. Scripts from a server have to be considered as malicious as ones from a web server. *CORE* Python developers have continually said that it is impossible to do this with python. - Python is very heavy, it requires inclusion of about 1.5mb of code. Scheme implementations can be as small as 5k of code! We also considered Lua, Javascript, C-script, our own language and another options. Don't get me wrong, I love Python - it was my first choice for a scripting language but all these issues made us choose scheme in the end. We didn't just jump into the solution, it took us a good 2 years to decide. > My proposal is to implement a client with the overlay mechanism and > scripting mechanism. It would include designing interfaces through > which the UI and game objects would be manipulated. > The client would be written for the .NET platform using the C# > language. The Python implementation I would embed would be IronPython > (written for .NET, fully compatible with the Python language). > The UI would be written using Windows Presentation Foundation. > The choice of .NET as a target platform is dictated by the following reasons: > - implementing the client is already a large task, so trying to make > it also multi-platform would not be a reasonable proposal, > - .NET is a modern technology, backed by professional tools that > ease the development process, > - having a native Windows client for TP would be a plus. I would point again to my first paragraph. The tpclient-pywx already looks and works like a native client on Windows thanks to wxWidgets. Improving this client would be a much better usage of our time (as it would also help Linux and Windows). Starting another client which has no advantages over the current one, that only benefits a small percentage of the community, in a language we have no existing code in, is just not something we wish to do. > The C# language is chosen as: > - it is THE language of the .NET platform, > - it's easy and powerful, > - it is fully interoperable with C++, so reimplementing the protocol > libraries would not be necessary. > My proposal would significantly enrich the clients. However other > clients would have to follow this active-client specification. That's > why before I post it on the SoC webapp, I want to ask weather the > direction in which this proposal is going is in line with your plans > for the future of TP. I thank you for your proposal and really like that you took the intuitive to propose your own idea, but I just don't think it's something we wish to pursue. You do seem very passionate about the project (which is a major plus) so I suggest that you put in a proposal for something different. Maybe helping improve tpclient-pywx under windows would be a good task. > Zbigniew Skowron Thank you for your time. Tim 'Mithro' Ansell Thousand Parsec Founder and Leader. _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
