gt-core design specification

[AndrewBerry]

I think we need to put our heads together and come up with a solid specification for the gt-core and it's interfaces.

Once we have the spec down, the gt-core code base will be much easier to maintain and we won't have all these merge problems where we end up with multiple accessors for the same variables (see: Torrent::getSize()/getWanted()/getTorrentSize()).

Also we'll have some real documentation- new UIs will be much easier to create.

[fuyukaidesu]

These belongs more in the "standards" part but :

• Decide on method naming conventions (getTextSomething or getSomethingString ? I've seen both in the Torrent class)
• Not include anything else than a single header in a cpp (Torrent.cpp should only include "Torrent.hpp" for example)
• Put constructors as the first method of their files.
• Remove inlines and const correctness until we have a stable release, these are a pain to debug and we only really need a subset of OOP.

[nyanpasu]

@shotxxxx Thanks for your input. I would appreciate more details. Where exactly should Core be split into smaller classes? It's pretty simple right now, but preventing all sorts of stupid C++ features being introduced is a personal mission of mine, and I'm sure there are other devs who also object to all the bloat and spaghetti.

[benwaffle]

@shotxxxx You can help by contributing to spec.md in the spec branch

[benwaffle]

libtorrent handles session serialization

[nyanpasu]

@shotxxxx I quite agree now.