meta data for this page
Code modifications to PeerHood_core to discuss about.
Inconsistent use of files
src/*.cc ⇒ libpeerhood.so
daemon/*.cc + ../src/(parts of *.cc) ⇒ phd, duplicate compile, causes linking errors
#warning to TODO
Todo issues should not seen on compile time.
- c++ compile generates a lot of messages, extra messages only confuses compile error tracking.
Naming: ph or peerhood ?
- libpeerhood.so VS
- ph-config – this is against gnu library use naming
- phd daemon
Plugings into own directories
- Plugin separation
- Plugin depenndencies
- Adding new plugin does not mess other source code
- Plugin based build convention
- TCPConnectio ? and use of it on different plugins
- multiple inclusion of same objectcode into different libraries ⇒ NO GOOD
Moved phd to go $(INSTALLDIR)/bin – Easier to use daemon for development, because bin is supposed to be in user default path. Although not pedantic, in practice daemon programs exists in /bin/ as well. – hevi
Platform configuration parameters should be stored for later use. – hevi
Documentation system ?
There is used certain javadoc like documentation system, what is it ? – hevi
Coding style ?
There is used a symbian like coding style, any referencies ? – hevi
Use of DEBUG
Debuging (or tracing backends) ? and use if them ? – hevi
test directory, which one are used
client-new client_roam server2 server3 server4 server-moi
DIRS = server2 client-new : are specified in Makefile – hevi
test directory, uses own MakeVars ?
Why ? – hevi