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
– hevi
#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.
– hevi
Naming: ph or peerhood ?
Inconsistency:
- libpeerhood.so VS
- ph-config – this is against gnu library use naming
- phd daemon
– hevi
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
– hevi
Installtion process
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
Platform configuration parameters should be stored for later use. – hevi
Documentation system ?
There is used certain javadoc like documentation system, what is it ? – hevi
Based of use of the @memo and @doc tags in incode documentation, it is supposed that DOC++ is used. – 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