While looking at the ice4j code to comment on Carl's request, I noticed
lots of deviations from the standard Java coding style and the Jitsi
adaptions. Examples are the "I" prefix in the interface, multiple
classes in one file, the use of Hungarian notation, and Pascal-Cased
Would you mind to clean that up?
Sure I'll fix that but I have a couple of questions.
That "I" in IPseudoTcpNotify class was because of the same name in
libjingle. I tried to keep the same names for all variables and thats
why there can be found variables like bConnect, nSent etc. I thought
that it may be easier to change anything in the protocol if some changes
may be added in libjingle version. Can I keep those Hungarian style
names as they are in PseudoTcpBase ?
Okay, I thought there was some kind of RFC for PseudoTCP and you just used
libjingle as a starting point. If Emil also agrees, you can keep the names
as in libjingle for only internally used stuff. But the public API must
conform to the Java standards.
I'll fix Pascal cases for all methods and "I" will be removed from
Regards classes in one file they are also only in PseudoTcpBase because I
thought that they don't make any sense to be used enywhere else. Some
enumerations next to those classes might be removed but I tried to keep
code as much similiar to that one in libjingle, however I am not sure if
makes sense. Will it be ok if I will make them nested classes of
PseudoTcpBase ? Or should I keep them as is, or put each one of them in as
separate file ?
I see no reason to let them inside the same file. It is easier to navigate
and understand code if each class has its own file. Being similar to
libjingle doesn't really help in a case where you need to re-sync code with
Option enumeration will be now public and I'll place it in a separate file
it should be used with setOption and getOption methods. However I need to
expose this functionality in target Socket class which we were talking
in as separate thread on the list.
Whatever option that is, please export it through PseudoTcpSocket and not
through the Impl.
PS: Could you please reply with plain-text mails?
2012/8/17 Ingo Bauersachs <email@example.com>