[sip-comm-dev] University discipline


#1

Hi Everybody,

I am a last year universit Student and this year I have to develop the "final project" as conclusion to my course, of computer engineering. My tutor gave the idea of helping in a open source project, as that wuold give me a real expirience in software developing.

I have been following the emails since january, and I have looked the project road map and the hole site. We thought about developing one or more Protocol Services, as named in the road map. Than, I hava asked Emil about my professor idea and he showed himself very interested.

Some doubts I Had:

About the protocol services I would like to work on, they would be,
without order of preference: SIP, Gadu Gadu, Jabber and MSN, althoug I
realy don't know this Gadu Gadu nor Jabber. As a university
discipline, i would have to write some documentation (requirements,
design, a test plan, etc...), no doubt a good idea for the project in
general and not only for me.

When it says implement Protocol Service SIP, what does it meant?
Shall we use other frameworks like JAIN SIP or other, or shall it be
an implementation in OSGi without using these framework??? I
understand it shall be a bundle, but using the exinting frameworks,
that i don't know.

About contributing with patches and fixes, where or how should I
start?? By doing it I know it will be easier to do contribute with
real code implementation. I looked at the site http://java.net, there
is a lot of open issues, but I don't know in which one(s) could I try
to help.

Thank you for your attention,

Regards Pedro

···

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


#2

Hello Pedro,

Pedro Oliveira wrote:

About the protocol services I would like to work on, they would be,
without order of preference: SIP, Gadu Gadu, Jabber and MSN, althoug I

Apart from SIP, (which exists in the old version and only needs to be
ported) you can take on any of these protocols. If you do not feel at ease with
Jabber and Gadu Gadu, then MSN is a great start.

realy don't know this Gadu Gadu nor Jabber. As a university
discipline, i would have to write some documentation (requirements,
design, a test plan, etc...), no doubt a good idea for the project in
general and not only for me.

I have some documentation to write on the Protocol Provider service
(which is the one that you'll be implementing if you decide to go ahead).
I'll mail the mailing list once ready.

When it says implement Protocol Service SIP, what does it meant?
Shall we use other frameworks like JAIN SIP or other, or shall it be
an implementation in OSGi without using these framework??? I
understand it shall be a bundle, but using the exinting frameworks,
that i don't know.

The old sip-communicator used the RI of jain-sip 1.1 (nist-sip-1.2).
While porting the old sip code to the new version we'll probably also
switch to jain-sip-1.2

About contributing with patches and fixes, where or how should I
start?? By doing it I know it will be easier to do contribute with
real code implementation. I looked at the site http://java.net, there
is a lot of open issues, but I don't know in which one(s) could I try
to help.

Veronique has recently created a "Getting Started" manual for
developers.

http://www.sip-communicator.org/index.php/Documentation/RetrievingAndBuildingTheSources

Try following the steps and let us know of any problems you
might meet. Once you're done I could point you to existing issues that
are good to start with and you may take them up if you wish.

Good luck!
Emil

···

Thank you for your attention,

Regards Pedro

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


#3

Hi Emil,

I agreed with my tutor on taking the MSN protocol service on, and also contribute with patches and fixing bugs. On that, you said you could point me "to existing issues that are good to start with and may take them up" and I accept it happly.

On the MSN protocol, I shall start writing some documentation, such as requirements, specification, design and etc, and if you have any requirement/tips/suggestions of your own, please say them freely.

Thanks and regards
Pedro

Emil Ivov wrote:

···

Hello Pedro,

Pedro Oliveira wrote:

About the protocol services I would like to work on, they would be,
without order of preference: SIP, Gadu Gadu, Jabber and MSN, althoug I

Apart from SIP, (which exists in the old version and only needs to be
ported) you can take on any of these protocols. If you do not feel at ease with
Jabber and Gadu Gadu, then MSN is a great start.

realy don't know this Gadu Gadu nor Jabber. As a university
discipline, i would have to write some documentation (requirements,
design, a test plan, etc...), no doubt a good idea for the project in
general and not only for me.

I have some documentation to write on the Protocol Provider service
(which is the one that you'll be implementing if you decide to go ahead).
I'll mail the mailing list once ready.

When it says implement Protocol Service SIP, what does it meant?
Shall we use other frameworks like JAIN SIP or other, or shall it be
an implementation in OSGi without using these framework??? I
understand it shall be a bundle, but using the exinting frameworks,
that i don't know.

The old sip-communicator used the RI of jain-sip 1.1 (nist-sip-1.2).
While porting the old sip code to the new version we'll probably also
switch to jain-sip-1.2

About contributing with patches and fixes, where or how should I
start?? By doing it I know it will be easier to do contribute with
real code implementation. I looked at the site http://java.net, there
is a lot of open issues, but I don't know in which one(s) could I try
to help.

Veronique has recently created a "Getting Started" manual for
developers.

http://www.sip-communicator.org/index.php/Documentation/RetrievingAndBuildingTheSources

Try following the steps and let us know of any problems you
might meet. Once you're done I could point you to existing issues that
are good to start with and you may take them up if you wish.

Good luck!
Emil

Thank you for your attention,

Regards Pedro

---------------------------------------------------------------------
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


#4

Hello Pedro,

Pedro Oliveira wrote:

I agreed with my tutor on taking the MSN protocol service on, and also contribute with patches and fixing bugs. On that, you said you could point me "to existing issues that are good to start with and may take them up" and I accept it happly.

Great! You can start by getting the code and here's how to do so

http://www.sip-communicator.org/index.php/Documentation/RetrievingAndBuildingTheSources

Once you have the source try and run the unit tests through the
cc-buildloop target. You seem to be running windows so the task would
definitely fail. That's where you come in ;).

There are two major reasons why cc-buildloop fails (one generic and the
other - windows specific).

1) On windows platforms there is a failure when trying to execute the
htmlreport task on line 284 in build.xml. The problem is in the "exec"
task and more precisely the

executable="ant"

param. I believe this comes from the fact that on windows we have both
ant.bat and ant.exe. executable="ant" seems to be wrongfully trying to
execute ant.exe instead of ant.bat. An easy way to fix this would be to
add some OS conditions in the build.xml and simply make sure we execute
ant.bat in the case of windows. Yet I'd like to keep platform specific
code in build.xml to a minimum so I'd strongly prefer another way of
dealing with this problem.

Something else you'd need to know: the reason for executing the
htmlreport task through an "exec" task rather than simply using
"ant" or "antcall" is that htmlreport uses the junitreport task which
needs xalan in the classpath. There is no way of making sure that xalan
is in the user classpath at the time ant is called so we'd have to find
a way of adding it there. The "exec" task would have done the job hadn't
it been for that OS file extension problem.

How does that sound? Willing to take it up?

2) The second (definitely less delicate and certainly less urgent)
reason for the failure of the cc-buildloop target is the fact that users
need to setup icq accounts (and in the future possibly other accounts as
well) and fill in the accounts.properties file accordingly. There's
nothing we could do to spare them the failure but we have to make sure
that the problem is well explained to the user. This would require both
adding a call to TestCase.fail() in the case of a missing
accounts.properties file as well as printing and shortly pausing the output on
an error message in the console.

If you feel that you cannot cope with the problem stated in 1) then you
could give this one a try.

On the MSN protocol, I shall start writing some documentation, such as requirements, specification, design and etc, and if you have any
requirement/tips/suggestions of your own, please say them freely.

Sounds good. I'll try and send you a couple of references to MSN stacks
tomorrow.

Good luck!
Emil

···

Thanks and regards Pedro

Emil Ivov wrote:

Hello Pedro,

Pedro Oliveira wrote:

About the protocol services I would like to work on, they would be, without order of preference: SIP, Gadu Gadu, Jabber and MSN,
althoug I

Apart from SIP, (which exists in the old version and only needs to
be ported) you can take on any of these protocols. If you do not feel at ease with Jabber and Gadu Gadu, then MSN is a great start.

realy don't know this Gadu Gadu nor Jabber. As a university discipline, i would have to write some documentation (requirements, design, a test plan, etc...), no doubt a good idea
for the project in general and not only for me.

I have some documentation to write on the Protocol Provider service
(which is the one that you'll be implementing if you decide to go
ahead). I'll mail the mailing list once ready.

When it says implement Protocol Service SIP, what does it meant? Shall we use other frameworks like JAIN SIP or other, or shall it
be an implementation in OSGi without using these framework??? I
understand it shall be a bundle, but using the exinting frameworks, that i don't know.

The old sip-communicator used the RI of jain-sip 1.1 (nist-sip-1.2). While porting the old sip code to the new version we'll probably also switch to jain-sip-1.2

About contributing with patches and fixes, where or how should I start?? By doing it I know it will be easier to do contribute with real code implementation. I looked at the site http://java.net, there is a lot of open issues, but I don't know
in which one(s) could I try to help.

Veronique has recently created a "Getting Started" manual for developers.

http://www.sip-communicator.org/index.php/Documentation/RetrievingAndBuildingTheSources

Try following the steps and let us know of any problems you might meet. Once you're done I could point you to existing issues that are good to start with and you may take them up if you wish.

Good luck! Emil

Thank you for your attention,

Regards Pedro

---------------------------------------------------------------------
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

Hello Emil,

I'll try to fix these two issues during this week, I'll feedback you on how that evolves.

I found some non official documentation on the MSN protocol, an IETF internet-draft and others IETF documents about instant messaging.

Lets see what happens, I hope I can bring great news!

Regards
Pedro

Emil Ivov wrote:

···

Hello Pedro,

Pedro Oliveira wrote:

I agreed with my tutor on taking the MSN protocol service on, and also contribute with patches and fixing bugs. On that, you said you could point me "to existing issues that are good to start with and may take them up" and I accept it happly.

Great! You can start by getting the code and here's how to do so

http://www.sip-communicator.org/index.php/Documentation/RetrievingAndBuildingTheSources

Once you have the source try and run the unit tests through the
cc-buildloop target. You seem to be running windows so the task would
definitely fail. That's where you come in ;).

There are two major reasons why cc-buildloop fails (one generic and the
other - windows specific).

1) On windows platforms there is a failure when trying to execute the
htmlreport task on line 284 in build.xml. The problem is in the "exec"
task and more precisely the

executable="ant"

param. I believe this comes from the fact that on windows we have both
ant.bat and ant.exe. executable="ant" seems to be wrongfully trying to
execute ant.exe instead of ant.bat. An easy way to fix this would be to
add some OS conditions in the build.xml and simply make sure we execute
ant.bat in the case of windows. Yet I'd like to keep platform specific
code in build.xml to a minimum so I'd strongly prefer another way of
dealing with this problem.

Something else you'd need to know: the reason for executing the
htmlreport task through an "exec" task rather than simply using
"ant" or "antcall" is that htmlreport uses the junitreport task which
needs xalan in the classpath. There is no way of making sure that xalan
is in the user classpath at the time ant is called so we'd have to find
a way of adding it there. The "exec" task would have done the job hadn't
it been for that OS file extension problem.

How does that sound? Willing to take it up?

2) The second (definitely less delicate and certainly less urgent)
reason for the failure of the cc-buildloop target is the fact that users
need to setup icq accounts (and in the future possibly other accounts as
well) and fill in the accounts.properties file accordingly. There's
nothing we could do to spare them the failure but we have to make sure
that the problem is well explained to the user. This would require both
adding a call to TestCase.fail() in the case of a missing
accounts.properties file as well as printing and shortly pausing the output on
an error message in the console.

If you feel that you cannot cope with the problem stated in 1) then you
could give this one a try.

On the MSN protocol, I shall start writing some documentation, such as requirements, specification, design and etc, and if you have any
requirement/tips/suggestions of your own, please say them freely.

Sounds good. I'll try and send you a couple of references to MSN stacks
tomorrow.

Good luck!
Emil

Thanks and regards Pedro

Emil Ivov wrote:

Hello Pedro,

Pedro Oliveira wrote:

About the protocol services I would like to work on, they would be, without order of preference: SIP, Gadu Gadu, Jabber and MSN,
althoug I

Apart from SIP, (which exists in the old version and only needs to
be ported) you can take on any of these protocols. If you do not feel at ease with Jabber and Gadu Gadu, then MSN is a great start.

realy don't know this Gadu Gadu nor Jabber. As a university discipline, i would have to write some documentation (requirements, design, a test plan, etc...), no doubt a good idea
for the project in general and not only for me.

I have some documentation to write on the Protocol Provider service
(which is the one that you'll be implementing if you decide to go
ahead). I'll mail the mailing list once ready.

When it says implement Protocol Service SIP, what does it meant? Shall we use other frameworks like JAIN SIP or other, or shall it
be an implementation in OSGi without using these framework??? I
understand it shall be a bundle, but using the exinting frameworks, that i don't know.

The old sip-communicator used the RI of jain-sip 1.1 (nist-sip-1.2). While porting the old sip code to the new version we'll probably also switch to jain-sip-1.2

About contributing with patches and fixes, where or how should I start?? By doing it I know it will be easier to do contribute with real code implementation. I looked at the site http://java.net, there is a lot of open issues, but I don't know
in which one(s) could I try to help.

Veronique has recently created a "Getting Started" manual for developers.

http://www.sip-communicator.org/index.php/Documentation/RetrievingAndBuildingTheSources

Try following the steps and let us know of any problems you might meet. Once you're done I could point you to existing issues that are good to start with and you may take them up if you wish.

Good luck! Emil

Thank you for your attention,

Regards Pedro

---------------------------------------------------------------------
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

---------------------------------------------------------------------
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


#6

Hello Pedro,

Glad to know you're making progress.

I found some non official documentation on the MSN protocol, an IETF
internet-draft and others IETF documents about instant messaging.

Last year we had two students: Guillermo Moscoso Del Prado and Fey
Lionel, who spent some time studying open source stacks for various IMP
protocols.

For MSN they had come up with the following two:

- JML

A library which they claim to be complete but scarcely documented.

There was also:

- JMML

http://www.planetmessenger.org

Which they successfully used for making a sample IM client supporting
MSN. It might worth taking a look at those two as well as looking around
for other existing protocol stacks.

Good luck!

Emil

···

Lets see what happens, I hope I can bring great news!

Regards Pedro

Emil Ivov wrote:

Hello Pedro,

Pedro Oliveira wrote:

I agreed with my tutor on taking the MSN protocol service on, and
also contribute with patches and fixing bugs. On that, you said
you could point me "to existing issues that are good to start
with and may take them up" and I accept it happly.

Great! You can start by getting the code and here's how to do so

http://www.sip-communicator.org/index.php/Documentation/RetrievingAndBuildingTheSources

Once you have the source try and run the unit tests through the cc-buildloop target. You seem to be running windows so the task
would definitely fail. That's where you come in ;).

There are two major reasons why cc-buildloop fails (one generic and
the other - windows specific).

1) On windows platforms there is a failure when trying to execute
the htmlreport task on line 284 in build.xml. The problem is in the
"exec" task and more precisely the

executable="ant"

param. I believe this comes from the fact that on windows we have
both ant.bat and ant.exe. executable="ant" seems to be wrongfully
trying to execute ant.exe instead of ant.bat. An easy way to fix
this would be to add some OS conditions in the build.xml and simply
make sure we execute ant.bat in the case of windows. Yet I'd like
to keep platform specific code in build.xml to a minimum so I'd
strongly prefer another way of dealing with this problem.

Something else you'd need to know: the reason for executing the htmlreport task through an "exec" task rather than simply using "ant" or "antcall" is that htmlreport uses the junitreport task
which needs xalan in the classpath. There is no way of making sure
that xalan is in the user classpath at the time ant is called so
we'd have to find a way of adding it there. The "exec" task would
have done the job hadn't it been for that OS file extension
problem.

How does that sound? Willing to take it up?

2) The second (definitely less delicate and certainly less urgent) reason for the failure of the cc-buildloop target is the fact that
users need to setup icq accounts (and in the future possibly other
accounts as well) and fill in the accounts.properties file
accordingly. There's nothing we could do to spare them the failure
but we have to make sure that the problem is well explained to the
user. This would require both adding a call to TestCase.fail() in
the case of a missing accounts.properties file as well as printing
and shortly pausing the output on an error message in the console.

If you feel that you cannot cope with the problem stated in 1) then
you could give this one a try.

On the MSN protocol, I shall start writing some documentation,
such as requirements, specification, design and etc, and if you
have any requirement/tips/suggestions of your own, please say
them freely.

Sounds good. I'll try and send you a couple of references to MSN
stacks tomorrow.

Good luck! Emil

Thanks and regards Pedro

Emil Ivov wrote:

Hello Pedro,

Pedro Oliveira wrote:

About the protocol services I would like to work on, they
would be, without order of preference: SIP, Gadu Gadu, Jabber
and MSN, althoug I

Apart from SIP, (which exists in the old version and only needs
to be ported) you can take on any of these protocols. If you do
not feel at ease with Jabber and Gadu Gadu, then MSN is a great
start.

realy don't know this Gadu Gadu nor Jabber. As a university discipline, i would have to write some documentation
(requirements, design, a test plan, etc...), no doubt a good
idea for the project in general and not only for me.

I have some documentation to write on the Protocol Provider
service (which is the one that you'll be implementing if you
decide to go ahead). I'll mail the mailing list once ready.

When it says implement Protocol Service SIP, what does it
meant? Shall we use other frameworks like JAIN SIP or other,
or shall it be an implementation in OSGi without using these
framework??? I understand it shall be a bundle, but using
the exinting frameworks, that i don't know.

The old sip-communicator used the RI of jain-sip 1.1
(nist-sip-1.2). While porting the old sip code to the new
version we'll probably also switch to jain-sip-1.2

About contributing with patches and fixes, where or how
should I start?? By doing it I know it will be easier to do
contribute with real code implementation. I looked at the
site http://java.net, there is a lot of open issues, but I
don't know in which one(s) could I try to help.

Veronique has recently created a "Getting Started" manual for developers.

http://www.sip-communicator.org/index.php/Documentation/RetrievingAndBuildingTheSources

Try following the steps and let us know of any problems you
might meet. Once you're done I could point you to existing
issues that are good to start with and you may take them up if
you wish.

Good luck! Emil

Thank you for your attention,

Regards Pedro

---------------------------------------------------------------------
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

---------------------------------------------------------------------
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