[sip-comm-dev] OTR - GSoC Progress by June 12


#1

Hello all!

I'd like to share some things about my progress with the project with
anyone who's interested in OTR support.

Last week, I did a relatively big code refactoring in the library.
First of, I purged some elements that where obtrusive like huge
javadocs and getters/setters. Both can be added at a later development
stage when the library will be relatively stable.

Simplified how messages are assembled/disassembled. Now one can
disassemble a message by calling the appropriate constructor, and can
assemble messages by calling the toString() method of a message
instance.

Implemented state transition handling and message reply dispatching
mechanism when receiving

    * Plain text messages (with or without whitespace)
    * Query messages
    * Error messages
    * D-H Commit messages
    * D-H key messages

Created or adopted existing test cases, for refactored functionality
(assemble/disassemble) and new functionality of handling state
transitions respectively.

The project now uses Mercurial. So anyone who'd like to get a glimpse
of the code can get a local copy of the repository with this command:

hg clone https://otr4j.googlecode.com/hg/ otr4j

Thanks everybody for your time,
Have a nice weekend :slight_smile:

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi George,

good to hear. I'll have a look at it during the next days.

What was the reason to use mercurial instead of svn? Can you
give some feedback?

Emil, you sent a mail some days ago discussing a possible move
to another open source platform (agree that java.net is fairly slow).
If (and only if) this would happen than IMHO we could also
think about replacing svn with a more modern souce code control system,
for example git or mercurial.

Regards,
Werner

Geekius Caesar schrieb:

···

Hello all!

I'd like to share some things about my progress with the project with
anyone who's interested in OTR support.

Last week, I did a relatively big code refactoring in the library.
First of, I purged some elements that where obtrusive like huge
javadocs and getters/setters. Both can be added at a later development
stage when the library will be relatively stable.

Simplified how messages are assembled/disassembled. Now one can
disassemble a message by calling the appropriate constructor, and can
assemble messages by calling the toString() method of a message
instance.

Implemented state transition handling and message reply dispatching
mechanism when receiving

    * Plain text messages (with or without whitespace)
    * Query messages
    * Error messages
    * D-H Commit messages
    * D-H key messages

Created or adopted existing test cases, for refactored functionality
(assemble/disassemble) and new functionality of handling state
transitions respectively.

The project now uses Mercurial. So anyone who'd like to get a glimpse
of the code can get a local copy of the repository with this command:

hg clone https://otr4j.googlecode.com/hg/ otr4j

Thanks everybody for your time,
Have a nice weekend :slight_smile:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hey Werner,

Nice to "see" you!

I'm also eager to try mercurial and git. At least for git, I've been
reading only the best of impressions.

What concerns me though and what stopped me from employing either of
them for the private repository of the G.729 project is the support
for them in widespread development environments. For example, git on
Windows seems to ring the bells of cygwin and msys and neither of them
strikes me as full-blown Windows-aware applications. On the Eclipse
side of the VCS support, CVS and Subversion look like the better
supported ones and I don't know how well either of mercurial and git
are integrated and how much of a priority they are for the Eclipse
community. I guess NetBeans may be more advanced in the area with
respect to mercurial because of Sun's interest in it and I have no
idea about git.

Best regards,
Lubomir

···

2009/6/13 Werner Dittmann <Werner.Dittmann@t-online.de>:

Hi George,

good to hear. I'll have a look at it during the next days.

What was the reason to use mercurial instead of svn? Can you
give some feedback?

Emil, you sent a mail some days ago discussing a possible move
to another open source platform (agree that java.net is fairly slow).
If (and only if) this would happen than IMHO we could also
think about replacing svn with a more modern souce code control system,
for example git or mercurial.

Regards,
Werner

Geekius Caesar schrieb:

Hello all!

I'd like to share some things about my progress with the project with
anyone who's interested in OTR support.

Last week, I did a relatively big code refactoring in the library.
First of, I purged some elements that where obtrusive like huge
javadocs and getters/setters. Both can be added at a later development
stage when the library will be relatively stable.

Simplified how messages are assembled/disassembled. Now one can
disassemble a message by calling the appropriate constructor, and can
assemble messages by calling the toString() method of a message
instance.

Implemented state transition handling and message reply dispatching
mechanism when receiving

\* Plain text messages \(with or without whitespace\)
\* Query messages
\* Error messages
\* D\-H Commit messages
\* D\-H key messages

Created or adopted existing test cases, for refactored functionality
(assemble/disassemble) and new functionality of handling state
transitions respectively.

The project now uses Mercurial. So anyone who'd like to get a glimpse
of the code can get a local copy of the repository with this command:

hg clone https://otr4j.googlecode.com/hg/ otr4j

Thanks everybody for your time,
Have a nice weekend :slight_smile:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hello Werner, Ulrich Lubinor and all!

What seems more important to me is

* It works offline -> it’s fast (two reasons)
* Less management (you don't need access to any centralized server,
just clone and work)
* Branching and merging is easy (after cloning and working, comes push)

In my humble (and simple) opinion, Mercurial (or Git maybe? haven't
touched that spooky thing yet..) just worked for me, *and* it's not
that different from SVN after all.

Here it's.. better explained!
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

···

On Sat, Jun 13, 2009 at 9:52 AM, Werner Dittmann<Werner.Dittmann@t-online.de> wrote:

Hi George,

good to hear. I'll have a look at it during the next days.

What was the reason to use mercurial instead of svn? Can you
give some feedback?

Emil, you sent a mail some days ago discussing a possible move
to another open source platform (agree that java.net is fairly slow).
If (and only if) this would happen than IMHO we could also
think about replacing svn with a more modern souce code control system,
for example git or mercurial.

Regards,
Werner

Geekius Caesar schrieb:

Hello all!

I'd like to share some things about my progress with the project with
anyone who's interested in OTR support.

Last week, I did a relatively big code refactoring in the library.
First of, I purged some elements that where obtrusive like huge
javadocs and getters/setters. Both can be added at a later development
stage when the library will be relatively stable.

Simplified how messages are assembled/disassembled. Now one can
disassemble a message by calling the appropriate constructor, and can
assemble messages by calling the toString() method of a message
instance.

Implemented state transition handling and message reply dispatching
mechanism when receiving

\* Plain text messages \(with or without whitespace\)
\* Query messages
\* Error messages
\* D\-H Commit messages
\* D\-H key messages

Created or adopted existing test cases, for refactored functionality
(assemble/disassemble) and new functionality of handling state
transitions respectively.

The project now uses Mercurial. So anyone who'd like to get a glimpse
of the code can get a local copy of the repository with this command:

hg clone https://otr4j.googlecode.com/hg/ otr4j

Thanks everybody for your time,
Have a nice weekend :slight_smile:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Just adding my own personal experience:

I used mercurial (favoring over git) in one of my last classes I
taught due to the horrible support for windows and for the reasons
listed at http://google-code-updates.blogspot.com/2009/04/mercurial-support-for-project-hosting.html

Lubomir is right: support in eclipse is very painful, especially if
you work with a new eclipse and mercurial version. There is a nice
eclipse plugin, but it didn't work reliable (maybe it does now) in the
newest version. A file explorer like tool TortoiseHG seemed to work
very fine for my students.

I had a little chat with Emil yesterday about the topic and we were
thinking that maybe addressing a switch to a mercurial (or git) based
repository might be a little too early at this point. However, both
git and mercurial support svn gateways, so you could easily create
your own local branch based on mercurial/git and still update and
contribute via svn. Maybe we should publish a little howto to allow
contributers to use this?

Cheers,
Uli

···

On Sat, Jun 13, 2009 at 1:59 PM, Lubomir Marinov<lubomir.marinov@gmail.com> wrote:

Hey Werner,

Nice to "see" you!

I'm also eager to try mercurial and git. At least for git, I've been
reading only the best of impressions.

What concerns me though and what stopped me from employing either of
them for the private repository of the G.729 project is the support
for them in widespread development environments. For example, git on
Windows seems to ring the bells of cygwin and msys and neither of them
strikes me as full-blown Windows-aware applications. On the Eclipse
side of the VCS support, CVS and Subversion look like the better
supported ones and I don't know how well either of mercurial and git
are integrated and how much of a priority they are for the Eclipse
community. I guess NetBeans may be more advanced in the area with
respect to mercurial because of Sun's interest in it and I have no
idea about git.

Best regards,
Lubomir

2009/6/13 Werner Dittmann <Werner.Dittmann@t-online.de>:

Hi George,

good to hear. I'll have a look at it during the next days.

What was the reason to use mercurial instead of svn? Can you
give some feedback?

Emil, you sent a mail some days ago discussing a possible move
to another open source platform (agree that java.net is fairly slow).
If (and only if) this would happen than IMHO we could also
think about replacing svn with a more modern souce code control system,
for example git or mercurial.

Regards,
Werner

Geekius Caesar schrieb:

Hello all!

I'd like to share some things about my progress with the project with
anyone who's interested in OTR support.

Last week, I did a relatively big code refactoring in the library.
First of, I purged some elements that where obtrusive like huge
javadocs and getters/setters. Both can be added at a later development
stage when the library will be relatively stable.

Simplified how messages are assembled/disassembled. Now one can
disassemble a message by calling the appropriate constructor, and can
assemble messages by calling the toString() method of a message
instance.

Implemented state transition handling and message reply dispatching
mechanism when receiving

\* Plain text messages \(with or without whitespace\)
\* Query messages
\* Error messages
\* D\-H Commit messages
\* D\-H key messages

Created or adopted existing test cases, for refactored functionality
(assemble/disassemble) and new functionality of handling state
transitions respectively.

The project now uses Mercurial. So anyone who'd like to get a glimpse
of the code can get a local copy of the repository with this command:

hg clone https://otr4j.googlecode.com/hg/ otr4j

Thanks everybody for your time,
Have a nice weekend :slight_smile:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
title+name: Dr. Ulrich Norbisrath
web: http://ulno.net; address+phone+fax: http://ulno.net/contact
google:unorbisrath@gmail.com; icq:46786247
mailto:ulno@ulno.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

I forgot to mention about third party support tools..

Any tool I've found is based on mercurial command line client
(TortoiseHg, NetBeans integrated client, Eclipse plugin), so I finally
sticked with the command line version (which supports Windows
natively, no Cygwin required). If you also use a cool third party
diffing tool it just makes your development experience awesome! I find
it really cool to be able to do hg cmdm (cmdm is a custom command that
spawns a custom diff/merge tool) and visualize all your changes from
all your files).

I describe here
http://otr4sipcomm.blogspot.com/2009/06/arsenal-selection.html how I
ended up using mercurial command line client and Sourcegear's
Diffmerge tool.

···

On Sat, Jun 13, 2009 at 2:54 PM, Geekius Caesar<geekius.caesar@gmail.com> wrote:

Hello Werner, Ulrich Lubinor and all!

What seems more important to me is

* It works offline -> it’s fast (two reasons)
* Less management (you don't need access to any centralized server,
just clone and work)
* Branching and merging is easy (after cloning and working, comes push)

In my humble (and simple) opinion, Mercurial (or Git maybe? haven't
touched that spooky thing yet..) just worked for me, *and* it's not
that different from SVN after all.

Here it's.. better explained!
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

On Sat, Jun 13, 2009 at 9:52 AM, Werner > Dittmann<Werner.Dittmann@t-online.de> wrote:

Hi George,

good to hear. I'll have a look at it during the next days.

What was the reason to use mercurial instead of svn? Can you
give some feedback?

Emil, you sent a mail some days ago discussing a possible move
to another open source platform (agree that java.net is fairly slow).
If (and only if) this would happen than IMHO we could also
think about replacing svn with a more modern souce code control system,
for example git or mercurial.

Regards,
Werner

Geekius Caesar schrieb:

Hello all!

I'd like to share some things about my progress with the project with
anyone who's interested in OTR support.

Last week, I did a relatively big code refactoring in the library.
First of, I purged some elements that where obtrusive like huge
javadocs and getters/setters. Both can be added at a later development
stage when the library will be relatively stable.

Simplified how messages are assembled/disassembled. Now one can
disassemble a message by calling the appropriate constructor, and can
assemble messages by calling the toString() method of a message
instance.

Implemented state transition handling and message reply dispatching
mechanism when receiving

\* Plain text messages \(with or without whitespace\)
\* Query messages
\* Error messages
\* D\-H Commit messages
\* D\-H key messages

Created or adopted existing test cases, for refactored functionality
(assemble/disassemble) and new functionality of handling state
transitions respectively.

The project now uses Mercurial. So anyone who'd like to get a glimpse
of the code can get a local copy of the repository with this command:

hg clone https://otr4j.googlecode.com/hg/ otr4j

Thanks everybody for your time,
Have a nice weekend :slight_smile:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net