Thanks for your responses! The changes are indeed very unlikely to destabilize the release branch. Of course, I'll rework the patch a bit before committing, moving the main => wesnoth_main renaming under #ifdef, and prettifying the scons changes (I'm thinking of replacing the ugly list of link flags with a series of configuration checks for the libraries).
I'm also ok with waiting for after the release, if you decide so. Websockets will require a considerable amount of client-side work first. They are a thing for the future. Fullscreen support will come pretty soon and, as it seems, will only require changes in JS and libSDL. I am ready to maintain the code, but would not commit on any deadlines for the future improvements. If you decide to serve the game from wesnoth.org, that will definitely generate some amount of traffic. The data is persistently cached on the client, so that makes it ~350M max per user, excluding the stuff that that particular client does not need (most campaigns for most users, for example). And, of course, updates. I don't have them fully figured out yet, but all filesystem metainfo is baked into the game binary, so updated binary with a different path mapping will fetch and use new files. And, since it is native code, we can do any tricks to save up bandwidth, like sending binary deltas. The big list of files is autogenerated. There is a script (part of the patch) for scanning an installation and building the list. For locally modified content - should be possible. I think there is feature in filesystem.cpp to search several locations when looking for any data file. We can have a writable html5 file system at a high-priority location, this way local changes will override the original files, but won't mess with future updates. Files can be copied from local disk to html5 fs with a browser "upload file" dialog - a slightly clumsy inteface, - or edited by any in-game means as normal files. On Tue, Nov 15, 2011 at 7:29 PM, jeremy rosen <[email protected]> wrote: >> >> But as Boucman already pointed out we are currently in feature freeze so I >> think adding your changes to mainline right now might be, uhm, problematic... >> I am not 100 sure how to best proceed here, comments and recommendations are >> welcome. >> > > the changes to our main code are minor (a couple of ifdef at most) > > the changes to our build system are more important but i'm not too > worried about the impact... (apparently nacl is scons only, so our > resident scons expert could have a look that would be great) > > there is a big chunk of additional stuff that is nacl only, so it > wouldn't impact normal builds (wrappers in html, that sort of > stuff....) > > so I am not too worried about impact on our normal code, and it's > basicly a choice between an unsuficiantly tested nacl port and no > (official) port at all. > > now, there is the case of websockets in the server > * they are not implemented at this point, so little chance to have > them in time for the next beta > * they are a more important change that might affect normal gameplay > thus needs more testing > * however once tested they would not affect normal gameplay. > > > so, my thoughts on a plan... > > * first, we need to hear a little more from Evgeniy before any > decision. In particular if he is ready to maintain this, and the > possible strain on the server > > at this point we have multiple ways to go, none seems absolutely bad > to me, and we can host it on wesnoth.org for testing... > > > WE COULD ADD IT BEFORE 1.10.0 > As I said I am not too worried about the impact on other builds, however > * there is no network, so it's a bit of a sub-par port until we add it > * we break the feature freeze which is a bad example > * we have little chance of testing > > WE COULD TARGET 1.10.1 > similar to the previous one, except we give ourself a little more > margin to see how it turns out and maybe to get the websocket code in > * the port has to wait longer and this is a "cool" feature so a good > idea to have in the key release > * we could have an "experimental release" of 1.10.0 for testing > without officially releasing it on wesnoth.org > > WE COULD TARGET 1.11 AND BACKPORT > * we have to wait for the branching of 1.11 > * that means a (probably simple) backport > > > my advice would be to add it to 1.10.0 with a big warning that it's > experimental and doesn't have network, test heavily websocks on 1.11 > and backport websocks on 1.10.1 once that's done > > Boucman > > _______________________________________________ > Wesnoth-dev mailing list > [email protected] > https://mail.gna.org/listinfo/wesnoth-dev > _______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
