Code modifications to PeerHood_core to discuss about.

Inconsistent use of files

src/*.cc ⇒

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 ?


  • 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


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


DIRS = server2 client-new : are specified in Makefile – hevi

test directory, uses own MakeVars ?

Why ? – hevi