> > Actually reimplementing network.?pp in terms of other network api was > a mistake. Basically the entire thing is a hack around SDL_net lacking > support for asynchronous I/O and many of its features don't make sense > otherwise. Once feature freeze phase before 1.10 passes I plan to > continue working on new network subsystem and I'd prefer to use asio > directly. I see little point in using another abstraction layer over > asio and and looking at ANA's source made me wary of its careless use of > threads and manual memory management. >
Good point! I agree that keeping the API in itself was not a good idea. However, the goal was to develop a simple-to-use abstraction layer on top of asio and then re-implement the current (at the time) functional (although poorly designed) API to use that. The latter, of course, was non advisable, it meant using an abstraction layer (library) for something not quite what it was designed for, may bugs insued from misinterpreting the original API methods. The other option was rummaging through every use of that API and rewriting that to use a new (better designed) API. In the context of GSoC (3 months of work) I think the work approach choices were fine. Writing a new API and rewriting every use of the network module most likely meant not meeting deadlines, and milestones have to be achieved at the middle of the project. Showing a partially implemented network module with no real changes to Wesnoth's code probably meant that not much progress was done on Wesnoth itself. But getting back on track, I would still argue that the abstraction layer is useful. ANA's API in itself is simple enough (you can look at it clearly generating Doxygen HTML documentation.) ANA's main shortcomings are a poor architecture and low level design (diamond inheritances and the like) which make for a confusing analysis of the library. Aside from that, I think the library (even though it's just an abstraction layer) has some potential. Furthermore, I would think that writing your own network subsystem using asio directly is a tougher job and fixing whatever issues you may see in ANA. Obviously, the choice is yours (or of whoever takes on the job.) Currently ANA is being used as a network library in a project for distributed scientific computing ( http://code.google.com/p/fud/ ) and about 4 people are using it actively. However, no real big-scale deployment has been made. My point is, it is currently performing as expected across the board (which doesn't mean much without a big-scale deployment.) Again, any insights you may need on ANA's details, I'm here. If you would like to discuss a new approach for a network rewrite I can probably pitch in as well. Now, since you mention "careless use of threads and manual memory management"... is there anything in particular that pops to your head from the current trunk at googlecode? Some changes to threads and memory handling were done http://code.google.com/p/ana-net/source/diff?spec=svn10&r=10&format=side&path=/trunk/src/asio/asio_server.cpp Thanks
_______________________________________________ Wesnoth-dev mailing list [email protected] https://mail.gna.org/listinfo/wesnoth-dev
