[sip-comm-dev] jxta and address book


#1

I just suddenly realised that for jxta, a peerid is also needed for each peer. This is the ID you use to contact another peer with.

I'm not too sure if you have set up the address book with the ability to add extensions?

Cheers
Nick

···

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters

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


#2

Hey Nick, all

Took me a while huh :). Well they say - better late than never, so here goes.

buzz lightyear wrote:

I just suddenly realised that for jxta, a peerid is also needed for each peer. This is the ID you use to contact another peer with.

All protocols in the SIP Communicator are represented by the ProtocolProviderService package. The package contains an interface called ContactID. This interface is implemented by the various protocols in the way they seem fit or in other words they could just as well wrap the implementation around a PeerID.

Incidentally, I am using the opportunity to ask whether someone out there would be a volunteer to start an implementation of the ProtocolProviderService over JXTA? I personally think that this would be a very cool thing to do!

Don't be shy! Step forward!

Cheers
Emil


#3

I'd be happy to do this once sip audio/video are in place.

Cheers
Nick

···

From: Emil Ivov <emil.ivov@gmail.com>
Reply-To: dev@sip-communicator.dev.java.net
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Volunteers for implementing JXTA support? (was: jxta and address book)
Date: Sun, 23 Apr 2006 06:16:31 +0200

Hey Nick, all

Took me a while huh :). Well they say - better late than never, so here goes.

buzz lightyear wrote:

I just suddenly realised that for jxta, a peerid is also needed for each peer. This is the ID you use to contact another peer with.

All protocols in the SIP Communicator are represented by the ProtocolProviderService package. The package contains an interface called ContactID. This interface is implemented by the various protocols in the way they seem fit or in other words they could just as well wrap the implementation around a PeerID.

Incidentally, I am using the opportunity to ask whether someone out there would be a volunteer to start an implementation of the ProtocolProviderService over JXTA? I personally think that this would be a very cool thing to do!

Don't be shy! Step forward!

Cheers
Emil

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

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 7.5 today! http://join.msn.com/messenger/overview

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


#4

Hi Emil and All,

I don't know if I can step forward in this case, as I have alredy said I am intending to develop the MSN protocol service. If it is related, I am realy looking forward to help with the ProtocolProviderService!! I might need background information on the design and how it works.

On the build.xml subject (ant task OS specific), I looked for more and in the documentaition I found it is written that writing the task that way (os param) is the suggested way!

I still have to add a call to TestCase.fail() in the case of a missing accounts.properties file as well as print and shortly pause the output on an error message in the console, I hope I can manage ir real soon!!!!

I found the following site as MSN reference too, it describes pretty well I would say:
http://www.hypothetic.org/docs/msn/general/overview.php

Best regards
Pedro

Emil Ivov wrote:

···

Hey Nick, all

Took me a while huh :). Well they say - better late than never, so here goes.

buzz lightyear wrote:

I just suddenly realised that for jxta, a peerid is also needed for each peer. This is the ID you use to contact another peer with.

All protocols in the SIP Communicator are represented by the ProtocolProviderService package. The package contains an interface called ContactID. This interface is implemented by the various protocols in the way they seem fit or in other words they could just as well wrap the implementation around a PeerID.

Incidentally, I am using the opportunity to ask whether someone out there would be a volunteer to start an implementation of the ProtocolProviderService over JXTA? I personally think that this would be a very cool thing to do!

Don't be shy! Step forward!

Cheers
Emil

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

Forgot to ask - when will the sip audio/video be ready?

...... hate to bring this up but ..... we're coming up to the anniversary at the end of May of when sip-communictor 1.0 with sip audio/video should have originally been ready .....

Cheers
Nick

···

From: "buzz lightyear" <buzzheavyyear@hotmail.com>
Reply-To: dev@sip-communicator.dev.java.net
To: dev@sip-communicator.dev.java.net
Subject: RE: [sip-comm-dev] Volunteers for implementing JXTA support? (was: jxta and addr
Date: Sun, 23 Apr 2006 14:46:22 +0000

I'd be happy to do this once sip audio/video are in place.

Cheers
Nick

From: Emil Ivov <emil.ivov@gmail.com>
Reply-To: dev@sip-communicator.dev.java.net
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Volunteers for implementing JXTA support? (was: jxta and address book)
Date: Sun, 23 Apr 2006 06:16:31 +0200

Hey Nick, all

Took me a while huh :). Well they say - better late than never, so here goes.

buzz lightyear wrote:

I just suddenly realised that for jxta, a peerid is also needed for each peer. This is the ID you use to contact another peer with.

All protocols in the SIP Communicator are represented by the ProtocolProviderService package. The package contains an interface called ContactID. This interface is implemented by the various protocols in the way they seem fit or in other words they could just as well wrap the implementation around a PeerID.

Incidentally, I am using the opportunity to ask whether someone out there would be a volunteer to start an implementation of the ProtocolProviderService over JXTA? I personally think that this would be a very cool thing to do!

Don't be shy! Step forward!

Cheers
Emil

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

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 7.5 today! http://join.msn.com/messenger/overview

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

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 7.5 today! http://join.msn.com/messenger/overview

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


#6

Hi Emil,

Great! Thanks for your support on this. I'm sure it will improve many new users experience with Sip Communicator.

Cheers
Dave
Emil Ivov wrote:

···

Hi guys,

Since, following our discussion in the "[sip-comm] Support running
Sipcommunicator" thread, I've made a few dependancy modifications of the
build.xml. "ant make run" is all you now need in order to execute the
project. Ant cc-buildloop is still the way to go for developers.

Cheers
Emil

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

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


#7

Hello Pedro,

Pedro Oliveira wrote:

Hi Emil and All,

I don't know if I can step forward in this case, as I have alredy
said I am intending to develop the MSN protocol service. If it is
related, I am realy looking forward to help with the
ProtocolProviderService!! I might need background information on the
design and how it works.

Well, if you no longer want to do MSN you are free to start hacking on
jxta. That's what open source is about- anyone could hack on whatever
they want. However I don't think either of them is less important than
the other so MSN is also quite a very good opportunity for a meaningful
contribution.

On the build.xml subject (ant task OS specific), I looked for more
and in the documentaition I found it is written that writing the task
that way (os param) is the suggested way!

All we really need is modify the classpath. I wonder whether this could
be done by the taskdef or typedef tasks?

I still have to add a call to TestCase.fail() in the case of a
missing accounts.properties file as well as print and shortly pause
the output on an error message in the console, I hope I can manage ir
real soon!!!!

Cool,

I found the following site as MSN reference too, it describes pretty
well I would say: http://www.hypothetic.org/docs/msn/general/overview.php

Yes looks nice. Have you tried using the stacks that I sent you a while
ago? Creating a new stack from scratch would be too much of a
development and a maintenance burden. Besides you'd be able to produce
something working much faster this way.

Cheers
Emil

···

Best regards Pedro

Emil Ivov wrote:

Hey Nick, all

Took me a while huh :). Well they say - better late than never, so
here goes.

buzz lightyear wrote:

I just suddenly realised that for jxta, a peerid is also needed
for each peer. This is the ID you use to contact another peer
with.

All protocols in the SIP Communicator are represented by the ProtocolProviderService package. The package contains an interface
called ContactID. This interface is implemented by the various protocols in the way they seem fit or in other words they could
just as well wrap the implementation around a PeerID.

Incidentally, I am using the opportunity to ask whether someone out
there would be a volunteer to start an implementation of the ProtocolProviderService over JXTA? I personally think that this
would be a very cool thing to do!

Don't be shy! Step forward!

Cheers Emil

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


#8

Hi Emil,

If it is one or another, I will keep with MSN.

I looked the MSN libraries sites, but i still have to look the deeply!

Could you explain a little bit more your classpath suggestion!!!

Thanks and regards
Pedro

Emil Ivov wrote:

···

Hello Pedro,

Pedro Oliveira wrote:

Hi Emil and All,

I don't know if I can step forward in this case, as I have alredy
said I am intending to develop the MSN protocol service. If it is
related, I am realy looking forward to help with the
ProtocolProviderService!! I might need background information on the
design and how it works.

Well, if you no longer want to do MSN you are free to start hacking on
jxta. That's what open source is about- anyone could hack on whatever
they want. However I don't think either of them is less important than
the other so MSN is also quite a very good opportunity for a meaningful
contribution.

On the build.xml subject (ant task OS specific), I looked for more
and in the documentaition I found it is written that writing the task
that way (os param) is the suggested way!

All we really need is modify the classpath. I wonder whether this could
be done by the taskdef or typedef tasks?

I still have to add a call to TestCase.fail() in the case of a
missing accounts.properties file as well as print and shortly pause
the output on an error message in the console, I hope I can manage ir
real soon!!!!

Cool,

I found the following site as MSN reference too, it describes pretty
well I would say: http://www.hypothetic.org/docs/msn/general/overview.php

Yes looks nice. Have you tried using the stacks that I sent you a while
ago? Creating a new stack from scratch would be too much of a
development and a maintenance burden. Besides you'd be able to produce
something working much faster this way.

Cheers
Emil

Best regards Pedro

Emil Ivov wrote:

Hey Nick, all

Took me a while huh :). Well they say - better late than never, so
here goes.

buzz lightyear wrote:

I just suddenly realised that for jxta, a peerid is also needed
for each peer. This is the ID you use to contact another peer
with.

All protocols in the SIP Communicator are represented by the ProtocolProviderService package. The package contains an interface
called ContactID. This interface is implemented by the various protocols in the way they seem fit or in other words they could
just as well wrap the implementation around a PeerID.

Incidentally, I am using the opportunity to ask whether someone out
there would be a volunteer to start an implementation of the ProtocolProviderService over JXTA? I personally think that this
would be a very cool thing to do!

Don't be shy! Step forward!

Cheers Emil

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


#9

Hello Nick,

Forgot to ask - when will the sip audio/video be ready?

It's hard to say. A month or two I guess.

...... hate to bring this up but ..... we're coming up to the
anniversary at the end of May of when sip-communictor 1.0 with sip
audio/video should have originally been ready .....

Oh it was originally previewed for the end of January 2005 so the 1 year
anniversary has come and gone.
We're doing what we can, and I think we're already seeing the light at
the end of the SIP Communicator crisis tunnel!

I'd be happy to do this once sip audio/video are in place.

Well, unless you have some other reason, you don't really need to wait
for them. All that's necessary to implement JXTA instant messaging and
presence is already there.

Cheers
Emil

···

Cheers Nick

From: Emil Ivov <emil.ivov@gmail.com> Reply-To:
dev@sip-communicator.dev.java.net To:
dev@sip-communicator.dev.java.net Subject: [sip-comm-dev]
Volunteers for implementing JXTA support? (was: jxta and address
book) Date: Sun, 23 Apr 2006 06:16:31 +0200

Hey Nick, all

Took me a while huh :). Well they say - better late than never,
so here goes.

buzz lightyear wrote:

I just suddenly realised that for jxta, a peerid is also needed
for each peer. This is the ID you use to contact another peer
with.

All protocols in the SIP Communicator are represented by the ProtocolProviderService package. The package contains an
interface called ContactID. This interface is implemented by the
various protocols in the way they seem fit or in other words they
could just as well wrap the implementation around a PeerID.

Incidentally, I am using the opportunity to ask whether someone
out there would be a volunteer to start an implementation of the
ProtocolProviderService over JXTA? I personally think that this
would be a very cool thing to do!

Don't be shy! Step forward!

Cheers Emil

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

_________________________________________________________________ Are you using the latest version of MSN Messenger? Download MSN
Messenger 7.5 today! http://join.msn.com/messenger/overview

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

_________________________________________________________________ Are
you using the latest version of MSN Messenger? Download MSN Messenger
7.5 today! http://join.msn.com/messenger/overview

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


#10

Hello Pedro,

Could you explain a little bit more your classpath suggestion!!!

The only reason we need to launch ant from inside the build.xml is because we need to modify the classpath of the VM that is running ant itself and add xalan to it. If we find another way of modifying this classpath, then we won't need to to launch ant at all. So I was wondering whether using taskdef and typedef could do that trick.

Emil

Pedro Oliveira wrote:

···

Hi Emil,

If it is one or another, I will keep with MSN.

I looked the MSN libraries sites, but i still have to look the deeply!

Could you explain a little bit more your classpath suggestion!!!

Thanks and regards
Pedro

Emil Ivov wrote:

Hello Pedro,

Pedro Oliveira wrote:

Hi Emil and All,

I don't know if I can step forward in this case, as I have alredy
said I am intending to develop the MSN protocol service. If it is
related, I am realy looking forward to help with the
ProtocolProviderService!! I might need background information on the
design and how it works.

Well, if you no longer want to do MSN you are free to start hacking on
jxta. That's what open source is about- anyone could hack on whatever
they want. However I don't think either of them is less important than
the other so MSN is also quite a very good opportunity for a meaningful
contribution.

On the build.xml subject (ant task OS specific), I looked for more
and in the documentaition I found it is written that writing the task
that way (os param) is the suggested way!

All we really need is modify the classpath. I wonder whether this could
be done by the taskdef or typedef tasks?

I still have to add a call to TestCase.fail() in the case of a
missing accounts.properties file as well as print and shortly pause
the output on an error message in the console, I hope I can manage ir
real soon!!!!

Cool,

I found the following site as MSN reference too, it describes pretty
well I would say: http://www.hypothetic.org/docs/msn/general/overview.php

Yes looks nice. Have you tried using the stacks that I sent you a while
ago? Creating a new stack from scratch would be too much of a
development and a maintenance burden. Besides you'd be able to produce
something working much faster this way.

Cheers
Emil

Best regards Pedro

Emil Ivov wrote:

Hey Nick, all

Took me a while huh :). Well they say - better late than never, so
here goes.

buzz lightyear wrote:

I just suddenly realised that for jxta, a peerid is also needed
for each peer. This is the ID you use to contact another peer
with.

All protocols in the SIP Communicator are represented by the ProtocolProviderService package. The package contains an interface
called ContactID. This interface is implemented by the various protocols in the way they seem fit or in other words they could
just as well wrap the implementation around a PeerID.

Incidentally, I am using the opportunity to ask whether someone out
there would be a volunteer to start an implementation of the ProtocolProviderService over JXTA? I personally think that this
would be a very cool thing to do!

Don't be shy! Step forward!

Cheers Emil

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


#11

Dave,

Thanks for reporting it Dave! I've acked your report on the contributions page.

Emil

Dave Trollope wrote:

···

Hi Emil,

Great! Thanks for your support on this. I'm sure it will improve many new users experience with Sip Communicator.

Cheers
Dave
Emil Ivov wrote:

Hi guys,

Since, following our discussion in the "[sip-comm] Support running
Sipcommunicator" thread, I've made a few dependancy modifications of the
build.xml. "ant make run" is all you now need in order to execute the
project. Ant cc-buildloop is still the way to go for developers.

Cheers
Emil

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

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


#12

Well I didn't expect that... but thanks!
Dave

Emil Ivov wrote:

···

Dave,

Thanks for reporting it Dave! I've acked your report on the contributions page.

Emil

Dave Trollope wrote:

Hi Emil,

Great! Thanks for your support on this. I'm sure it will improve many new users experience with Sip Communicator.

Cheers
Dave
Emil Ivov wrote:

Hi guys,

Since, following our discussion in the "[sip-comm] Support running
Sipcommunicator" thread, I've made a few dependancy modifications of the
build.xml. "ant make run" is all you now need in order to execute the
project. Ant cc-buildloop is still the way to go for developers.

Cheers
Emil

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

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

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

--
David Trollope BSc(Hons) MIAP
Lucent Technologies
Tel/Fax: (630)713-9110
Email: trollope@lucent.com
         
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: users-help@sip-communicator.dev.java.net


#13

I'll put together a rough proposal and a skeleton ProtocolProviderService implementation over the next week or so.

If someone is already working on the sip audeo/video service then please send me a mail - some thought needs to go into the media and sip streams/pipes/sockets etc

Cheers
Nick

···

From: Emil Ivov <emil.ivov@gmail.com>
Reply-To: dev@sip-communicator.dev.java.net
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Volunteers for implementing JXTA support? (was: jxta and addr
Date: Tue, 25 Apr 2006 04:12:39 +0200

Hello Nick,

Forgot to ask - when will the sip audio/video be ready?

It's hard to say. A month or two I guess.

...... hate to bring this up but ..... we're coming up to the
anniversary at the end of May of when sip-communictor 1.0 with sip
audio/video should have originally been ready .....

Oh it was originally previewed for the end of January 2005 so the 1 year
anniversary has come and gone.
We're doing what we can, and I think we're already seeing the light at
the end of the SIP Communicator crisis tunnel!

I'd be happy to do this once sip audio/video are in place.

Well, unless you have some other reason, you don't really need to wait
for them. All that's necessary to implement JXTA instant messaging and
presence is already there.

Cheers
Emil

Cheers Nick

From: Emil Ivov <emil.ivov@gmail.com> Reply-To:
dev@sip-communicator.dev.java.net To:
dev@sip-communicator.dev.java.net Subject: [sip-comm-dev]
Volunteers for implementing JXTA support? (was: jxta and address
book) Date: Sun, 23 Apr 2006 06:16:31 +0200

Hey Nick, all

Took me a while huh :). Well they say - better late than never,
so here goes.

buzz lightyear wrote:

I just suddenly realised that for jxta, a peerid is also needed
for each peer. This is the ID you use to contact another peer
with.

All protocols in the SIP Communicator are represented by the ProtocolProviderService package. The package contains an
interface called ContactID. This interface is implemented by the
various protocols in the way they seem fit or in other words they
could just as well wrap the implementation around a PeerID.

Incidentally, I am using the opportunity to ask whether someone
out there would be a volunteer to start an implementation of the
ProtocolProviderService over JXTA? I personally think that this
would be a very cool thing to do!

Don't be shy! Step forward!

Cheers Emil

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

_________________________________________________________________ Are you using the latest version of MSN Messenger? Download MSN
Messenger 7.5 today! http://join.msn.com/messenger/overview

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

_________________________________________________________________ Are
you using the latest version of MSN Messenger? Download MSN Messenger
7.5 today! http://join.msn.com/messenger/overview

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

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

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


#14

Hi Nick,

buzz lightyear wrote:

I'll put together a rough proposal and a skeleton ProtocolProviderService implementation over the next week or so.

Hey hey! Am I glad to hear that!

If someone is already working on the sip audeo/video service then please send me a mail - some thought needs to go into the media and sip streams/pipes/sockets etc

Will do Nick.

Cheers
Emil

···

Cheers
Nick

From: Emil Ivov <emil.ivov@gmail.com>
Reply-To: dev@sip-communicator.dev.java.net
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Volunteers for implementing JXTA support? (was: jxta and addr
Date: Tue, 25 Apr 2006 04:12:39 +0200

Hello Nick,

Forgot to ask - when will the sip audio/video be ready?

It's hard to say. A month or two I guess.

...... hate to bring this up but ..... we're coming up to the
anniversary at the end of May of when sip-communictor 1.0 with sip
audio/video should have originally been ready .....

Oh it was originally previewed for the end of January 2005 so the 1 year
anniversary has come and gone.
We're doing what we can, and I think we're already seeing the light at
the end of the SIP Communicator crisis tunnel!

I'd be happy to do this once sip audio/video are in place.

Well, unless you have some other reason, you don't really need to wait
for them. All that's necessary to implement JXTA instant messaging and
presence is already there.

Cheers
Emil

Cheers Nick

From: Emil Ivov <emil.ivov@gmail.com> Reply-To:
dev@sip-communicator.dev.java.net To:
dev@sip-communicator.dev.java.net Subject: [sip-comm-dev]
Volunteers for implementing JXTA support? (was: jxta and address
book) Date: Sun, 23 Apr 2006 06:16:31 +0200

Hey Nick, all

Took me a while huh :). Well they say - better late than never,
so here goes.

buzz lightyear wrote:

I just suddenly realised that for jxta, a peerid is also needed
for each peer. This is the ID you use to contact another peer
with.

All protocols in the SIP Communicator are represented by the ProtocolProviderService package. The package contains an
interface called ContactID. This interface is implemented by the
various protocols in the way they seem fit or in other words they
could just as well wrap the implementation around a PeerID.

Incidentally, I am using the opportunity to ask whether someone
out there would be a volunteer to start an implementation of the
ProtocolProviderService over JXTA? I personally think that this
would be a very cool thing to do!

Don't be shy! Step forward!

Cheers Emil

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

_________________________________________________________________ Are you using the latest version of MSN Messenger? Download MSN
Messenger 7.5 today! http://join.msn.com/messenger/overview

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

_________________________________________________________________ Are
you using the latest version of MSN Messenger? Download MSN Messenger
7.5 today! http://join.msn.com/messenger/overview

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

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

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


#15

Apologies for not getting back sooner.

I've been thinking about the best approach for using jxta within sip-communicator and I'm beginning to favour some sort of factory with which protocols can register themselves and request pipes/streams to be created between peers - in the sip-communicator context, jxta is acting as more of a transport than a protocol to an external service (yes, the protocol maybe routed back to another sip-communicator).

The jxta protocol/transport will listen to, and broadcast the presence status, of the user, and also respond correctly reflectin the users contact list.

To recap, briefly, on jxta, peers communicate with each other by initially contacting a jxta rendezvous, discover other peers and then talk directly with each other. For those peers that are behind a hard firewall, they need to go through the firewall via a jxta relay.

Jxta peers start in an initial peergroup and then can create additional peer groups, join the peergroups; create services in any of the peergroups and use the various services offered by other peers via pipes - sockets or messages (messages are xml, with subclasses of byte[] and string).... and sockets chunk everything into byte[] and use the pipes.

So, by offering a jxta factory by which sip, icq etc have the freedom to create any number of streams/pipes between peers and their respective protocols, this, surely, should be flexible enough?

I hope I'm going in the right direction here for everyone?

I'm out for the whole of next week, but intend devoting the following week to writing a skeleton and commiting it (lgpl, of course).

Cheers
Nick

···

From: Emil Ivov <emil.ivov@gmail.com>
Reply-To: dev@sip-communicator.dev.java.net
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Volunteers for implementing JXTA support? (was: jxta and addr
Date: Tue, 25 Apr 2006 14:39:43 +0200

Hi Nick,

buzz lightyear wrote:

I'll put together a rough proposal and a skeleton ProtocolProviderService implementation over the next week or so.

Hey hey! Am I glad to hear that!

If someone is already working on the sip audeo/video service then please send me a mail - some thought needs to go into the media and sip streams/pipes/sockets etc

Will do Nick.

Cheers
Emil

Cheers
Nick

From: Emil Ivov <emil.ivov@gmail.com>
Reply-To: dev@sip-communicator.dev.java.net
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Volunteers for implementing JXTA support? (was: jxta and addr
Date: Tue, 25 Apr 2006 04:12:39 +0200

Hello Nick,

Forgot to ask - when will the sip audio/video be ready?

It's hard to say. A month or two I guess.

...... hate to bring this up but ..... we're coming up to the
anniversary at the end of May of when sip-communictor 1.0 with sip
audio/video should have originally been ready .....

Oh it was originally previewed for the end of January 2005 so the 1 year
anniversary has come and gone.
We're doing what we can, and I think we're already seeing the light at
the end of the SIP Communicator crisis tunnel!

I'd be happy to do this once sip audio/video are in place.

Well, unless you have some other reason, you don't really need to wait
for them. All that's necessary to implement JXTA instant messaging and
presence is already there.

Cheers
Emil

Cheers Nick

From: Emil Ivov <emil.ivov@gmail.com> Reply-To:
dev@sip-communicator.dev.java.net To:
dev@sip-communicator.dev.java.net Subject: [sip-comm-dev]
Volunteers for implementing JXTA support? (was: jxta and address
book) Date: Sun, 23 Apr 2006 06:16:31 +0200

Hey Nick, all

Took me a while huh :). Well they say - better late than never,
so here goes.

buzz lightyear wrote:

I just suddenly realised that for jxta, a peerid is also needed
for each peer. This is the ID you use to contact another peer
with.

All protocols in the SIP Communicator are represented by the ProtocolProviderService package. The package contains an
interface called ContactID. This interface is implemented by the
various protocols in the way they seem fit or in other words they
could just as well wrap the implementation around a PeerID.

Incidentally, I am using the opportunity to ask whether someone
out there would be a volunteer to start an implementation of the
ProtocolProviderService over JXTA? I personally think that this
would be a very cool thing to do!

Don't be shy! Step forward!

Cheers Emil

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

_________________________________________________________________ Are you using the latest version of MSN Messenger? Download MSN
Messenger 7.5 today! http://join.msn.com/messenger/overview

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

_________________________________________________________________ Are
you using the latest version of MSN Messenger? Download MSN Messenger
7.5 today! http://join.msn.com/messenger/overview

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

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

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

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters

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


#16

Hello Nick,

Glad to hear from you again.

There are basically two ways one would integrate jxta (or any other protocol for that matter) in the sip communicator and each of them is on a different level.

The ProtocolProviderService level is meant to offer a black box interface to instant messaging and telephony destined for high level bundles such as the GUI. A jxta implementation of this service would therefore have to implement its own instant messaging and telephony routines (if any). Concurrent ProtocolProviderService implementations _do_not_ refer to each other.

What you are talking about is a lower level that would be exporting interfaces to all jxta specific stuff so that other protocols would use it. Right now this is something we don't really need since no other protocol provider is even close to using jxta and if some do one day we have no idea which ones and how they'll be using it.

I saw on jxta.org that they have jxta specific instant messaging. It would be nice if we could start there. In other words implementing a jxta protocol provider that also implements the presence and IM operation sets would be nice.

How does this sound?

Emil

buzz lightyear wrote:

···

Apologies for not getting back sooner.

I've been thinking about the best approach for using jxta within sip-communicator and I'm beginning to favour some sort of factory with which protocols can register themselves and request pipes/streams to be created between peers - in the sip-communicator context, jxta is acting as more of a transport than a protocol to an external service (yes, the protocol maybe routed back to another sip-communicator).

The jxta protocol/transport will listen to, and broadcast the presence status, of the user, and also respond correctly reflectin the users contact list.

To recap, briefly, on jxta, peers communicate with each other by initially contacting a jxta rendezvous, discover other peers and then talk directly with each other. For those peers that are behind a hard firewall, they need to go through the firewall via a jxta relay.

Jxta peers start in an initial peergroup and then can create additional peer groups, join the peergroups; create services in any of the peergroups and use the various services offered by other peers via pipes - sockets or messages (messages are xml, with subclasses of byte[] and string).... and sockets chunk everything into byte[] and use the pipes.

So, by offering a jxta factory by which sip, icq etc have the freedom to create any number of streams/pipes between peers and their respective protocols, this, surely, should be flexible enough?

I hope I'm going in the right direction here for everyone?

I'm out for the whole of next week, but intend devoting the following week to writing a skeleton and commiting it (lgpl, of course).

Cheers
Nick

From: Emil Ivov <emil.ivov@gmail.com>
Reply-To: dev@sip-communicator.dev.java.net
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Volunteers for implementing JXTA support? (was: jxta and addr
Date: Tue, 25 Apr 2006 14:39:43 +0200

Hi Nick,

buzz lightyear wrote:

I'll put together a rough proposal and a skeleton ProtocolProviderService implementation over the next week or so.

Hey hey! Am I glad to hear that!

If someone is already working on the sip audeo/video service then please send me a mail - some thought needs to go into the media and sip streams/pipes/sockets etc

Will do Nick.

Cheers
Emil

Cheers
Nick

From: Emil Ivov <emil.ivov@gmail.com>
Reply-To: dev@sip-communicator.dev.java.net
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Volunteers for implementing JXTA support? (was: jxta and addr
Date: Tue, 25 Apr 2006 04:12:39 +0200

Hello Nick,

Forgot to ask - when will the sip audio/video be ready?

It's hard to say. A month or two I guess.

...... hate to bring this up but ..... we're coming up to the
anniversary at the end of May of when sip-communictor 1.0 with sip
audio/video should have originally been ready .....

Oh it was originally previewed for the end of January 2005 so the 1 year
anniversary has come and gone.
We're doing what we can, and I think we're already seeing the light at
the end of the SIP Communicator crisis tunnel!

I'd be happy to do this once sip audio/video are in place.

Well, unless you have some other reason, you don't really need to wait
for them. All that's necessary to implement JXTA instant messaging and
presence is already there.

Cheers
Emil

Cheers Nick

From: Emil Ivov <emil.ivov@gmail.com> Reply-To:
dev@sip-communicator.dev.java.net To:
dev@sip-communicator.dev.java.net Subject: [sip-comm-dev]
Volunteers for implementing JXTA support? (was: jxta and address
book) Date: Sun, 23 Apr 2006 06:16:31 +0200

Hey Nick, all

Took me a while huh :). Well they say - better late than never,
so here goes.

buzz lightyear wrote:

I just suddenly realised that for jxta, a peerid is also needed
for each peer. This is the ID you use to contact another peer
with.

All protocols in the SIP Communicator are represented by the ProtocolProviderService package. The package contains an
interface called ContactID. This interface is implemented by the
various protocols in the way they seem fit or in other words they
could just as well wrap the implementation around a PeerID.

Incidentally, I am using the opportunity to ask whether someone
out there would be a volunteer to start an implementation of the
ProtocolProviderService over JXTA? I personally think that this
would be a very cool thing to do!

Don't be shy! Step forward!

Cheers Emil

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

_________________________________________________________________ Are you using the latest version of MSN Messenger? Download MSN
Messenger 7.5 today! http://join.msn.com/messenger/overview

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

_________________________________________________________________ Are
you using the latest version of MSN Messenger? Download MSN Messenger
7.5 today! http://join.msn.com/messenger/overview

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

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

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

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters

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


#17

Hi Emil

My interest really is with implementing standard protocols, such as sip, over jxta. You can already use myjxta2 for video, audio and messaging via jxta.

Sincere apologies for offering do this and now pull out, and hope that sip-communicator really challenges skype!

Best of luck.

Cheers
Nick

···

From: Emil Ivov <emil.ivov@gmail.com>
Reply-To: dev@sip-communicator.dev.java.net
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Volunteers for implementing JXTA support?
Date: Fri, 12 May 2006 11:10:03 +0200

Hello Nick,

Glad to hear from you again.

There are basically two ways one would integrate jxta (or any other protocol for that matter) in the sip communicator and each of them is on a different level.

The ProtocolProviderService level is meant to offer a black box interface to instant messaging and telephony destined for high level bundles such as the GUI. A jxta implementation of this service would therefore have to implement its own instant messaging and telephony routines (if any). Concurrent ProtocolProviderService implementations _do_not_ refer to each other.

What you are talking about is a lower level that would be exporting interfaces to all jxta specific stuff so that other protocols would use it. Right now this is something we don't really need since no other protocol provider is even close to using jxta and if some do one day we have no idea which ones and how they'll be using it.

I saw on jxta.org that they have jxta specific instant messaging. It would be nice if we could start there. In other words implementing a jxta protocol provider that also implements the presence and IM operation sets would be nice.

How does this sound?

Emil

buzz lightyear wrote:

Apologies for not getting back sooner.

I've been thinking about the best approach for using jxta within sip-communicator and I'm beginning to favour some sort of factory with which protocols can register themselves and request pipes/streams to be created between peers - in the sip-communicator context, jxta is acting as more of a transport than a protocol to an external service (yes, the protocol maybe routed back to another sip-communicator).

The jxta protocol/transport will listen to, and broadcast the presence status, of the user, and also respond correctly reflectin the users contact list.

To recap, briefly, on jxta, peers communicate with each other by initially contacting a jxta rendezvous, discover other peers and then talk directly with each other. For those peers that are behind a hard firewall, they need to go through the firewall via a jxta relay.

Jxta peers start in an initial peergroup and then can create additional peer groups, join the peergroups; create services in any of the peergroups and use the various services offered by other peers via pipes - sockets or messages (messages are xml, with subclasses of byte[] and string).... and sockets chunk everything into byte[] and use the pipes.

So, by offering a jxta factory by which sip, icq etc have the freedom to create any number of streams/pipes between peers and their respective protocols, this, surely, should be flexible enough?

I hope I'm going in the right direction here for everyone?

I'm out for the whole of next week, but intend devoting the following week to writing a skeleton and commiting it (lgpl, of course).

Cheers
Nick

From: Emil Ivov <emil.ivov@gmail.com>
Reply-To: dev@sip-communicator.dev.java.net
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Volunteers for implementing JXTA support? (was: jxta and addr
Date: Tue, 25 Apr 2006 14:39:43 +0200

Hi Nick,

buzz lightyear wrote:

I'll put together a rough proposal and a skeleton ProtocolProviderService implementation over the next week or so.

Hey hey! Am I glad to hear that!

If someone is already working on the sip audeo/video service then please send me a mail - some thought needs to go into the media and sip streams/pipes/sockets etc

Will do Nick.

Cheers
Emil

Cheers
Nick

From: Emil Ivov <emil.ivov@gmail.com>
Reply-To: dev@sip-communicator.dev.java.net
To: dev@sip-communicator.dev.java.net
Subject: Re: [sip-comm-dev] Volunteers for implementing JXTA support? (was: jxta and addr
Date: Tue, 25 Apr 2006 04:12:39 +0200

Hello Nick,

Forgot to ask - when will the sip audio/video be ready?

It's hard to say. A month or two I guess.

...... hate to bring this up but ..... we're coming up to the
anniversary at the end of May of when sip-communictor 1.0 with sip
audio/video should have originally been ready .....

Oh it was originally previewed for the end of January 2005 so the 1 year
anniversary has come and gone.
We're doing what we can, and I think we're already seeing the light at
the end of the SIP Communicator crisis tunnel!

I'd be happy to do this once sip audio/video are in place.

Well, unless you have some other reason, you don't really need to wait
for them. All that's necessary to implement JXTA instant messaging and
presence is already there.

Cheers
Emil

Cheers Nick

From: Emil Ivov <emil.ivov@gmail.com> Reply-To:
dev@sip-communicator.dev.java.net To:
dev@sip-communicator.dev.java.net Subject: [sip-comm-dev]
Volunteers for implementing JXTA support? (was: jxta and address
book) Date: Sun, 23 Apr 2006 06:16:31 +0200

Hey Nick, all

Took me a while huh :). Well they say - better late than never,
so here goes.

buzz lightyear wrote:

I just suddenly realised that for jxta, a peerid is also needed
for each peer. This is the ID you use to contact another peer
with.

All protocols in the SIP Communicator are represented by the ProtocolProviderService package. The package contains an
interface called ContactID. This interface is implemented by the
various protocols in the way they seem fit or in other words they
could just as well wrap the implementation around a PeerID.

Incidentally, I am using the opportunity to ask whether someone
out there would be a volunteer to start an implementation of the
ProtocolProviderService over JXTA? I personally think that this
would be a very cool thing to do!

Don't be shy! Step forward!

Cheers Emil

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

_________________________________________________________________ Are you using the latest version of MSN Messenger? Download MSN
Messenger 7.5 today! http://join.msn.com/messenger/overview

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

_________________________________________________________________ Are
you using the latest version of MSN Messenger? Download MSN Messenger
7.5 today! http://join.msn.com/messenger/overview

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

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

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

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters

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

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters

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


#18

Hello Nick,

buzz lightyear wrote:

Hi Emil

My interest really is with implementing standard protocols, such as sip, over jxta.

Well things like this would involve much research. If this is what
interests you could surely do it. It's open source we're dealing with
here so you are free to do whatever you like. Integrating it in the
sip-communicator source tree might not come quickly since research
matters like this require much evaluation and testing. Yet you don't
really need it to be a part of the project right from the beginning in order
to work on it. It's your call.

You can already use myjxta2 for video, audio and messaging via jxta.

Now that's something else and it could easily fit the sip-comm as it is
since it could easily be implemented in a separate jxta bundle and plug
nicely in the OSGI. If I understand correctly this is something you
are not interested in doing though so it's a pity.

Sincere apologies for offering do this and now pull out,

No problem Nick. We've all been there

Cheers
Emil

···

and hope that sip-communicator really challenges skype!

Best of luck.

Cheers Nick

From: Emil Ivov <emil.ivov@gmail.com> Reply-To: dev@sip-communicator.dev.java.net To: dev@sip-communicator.dev.java.net Subject: Re: [sip-comm-dev] Volunteers for implementing JXTA support? Date: Fri, 12 May 2006 11:10:03 +0200

Hello Nick,

Glad to hear from you again.

There are basically two ways one would integrate jxta (or any other
protocol for that matter) in the sip communicator and each of them
is on a different level.

The ProtocolProviderService level is meant to offer a black box interface to instant messaging and telephony destined for high level bundles such as the GUI. A jxta implementation of this service would therefore have to implement its own instant messaging
and telephony routines (if any). Concurrent ProtocolProviderService implementations _do_not_ refer to each other.

What you are talking about is a lower level that would be exporting
interfaces to all jxta specific stuff so that other protocols would use it. Right now this is something we don't really need since no other protocol provider is even close to using jxta and if
some do one day we have no idea which ones and how they'll be using it.

I saw on jxta.org that they have jxta specific instant messaging. It would be nice if we could start there. In other words implementing a jxta protocol provider that also implements the presence and IM operation sets would be nice.

How does this sound?

Emil

buzz lightyear wrote:

Apologies for not getting back sooner.

I've been thinking about the best approach for using jxta within
sip-communicator and I'm beginning to favour some sort of
factory with which protocols can register themselves and request
pipes/streams to be created between peers - in the sip-communicator context, jxta is acting as more of a transport than a protocol to an external service (yes, the protocol maybe routed back to another sip-communicator).

The jxta protocol/transport will listen to, and broadcast the presence status, of the user, and also respond correctly reflectin the users contact list.

To recap, briefly, on jxta, peers communicate with each other by
initially contacting a jxta rendezvous, discover other peers and
then talk directly with each other. For those peers that are behind a hard firewall, they need to go through the firewall via
a jxta relay.

Jxta peers start in an initial peergroup and then can create additional peer groups, join the peergroups; create services in any of the peergroups and use the various services offered by other peers via pipes - sockets or messages (messages are xml, with subclasses of byte[] and string).... and sockets chunk everything into byte[] and use the pipes.

So, by offering a jxta factory by which sip, icq etc have the freedom to create any number of streams/pipes between peers and their respective protocols, this, surely, should be flexible enough?

I hope I'm going in the right direction here for everyone?

I'm out for the whole of next week, but intend devoting the following week to writing a skeleton and commiting it (lgpl, of course).

Cheers Nick

From: Emil Ivov <emil.ivov@gmail.com> Reply-To: dev@sip-communicator.dev.java.net To: dev@sip-communicator.dev.java.net Subject: Re: [sip-comm-dev] Volunteers for implementing JXTA support? (was: jxta and addr Date: Tue, 25 Apr 2006 14:39:43 +0200

Hi Nick,

buzz lightyear wrote:

I'll put together a rough proposal and a skeleton ProtocolProviderService implementation over the next week or
so.

Hey hey! Am I glad to hear that!

If someone is already working on the sip audeo/video service
then please send me a mail - some thought needs to go into the media and sip streams/pipes/sockets etc

Will do Nick.

Cheers Emil

Cheers Nick

From: Emil Ivov <emil.ivov@gmail.com> Reply-To: dev@sip-communicator.dev.java.net To: dev@sip-communicator.dev.java.net Subject: Re: [sip-comm-dev] Volunteers for implementing JXTA support? (was: jxta and addr Date: Tue, 25 Apr 2006 04:12:39 +0200

Hello Nick,

Forgot to ask - when will the sip audio/video be ready?

It's hard to say. A month or two I guess.

...... hate to bring this up but ..... we're coming up to
the anniversary at the end of May of when sip-communictor 1.0 with sip audio/video should have originally been ready .....

Oh it was originally previewed for the end of January 2005
so the 1 year anniversary has come and gone. We're doing what we can, and I think we're already seeing the light at the end of the SIP Communicator crisis tunnel!

I'd be happy to do this once sip audio/video are in place.

Well, unless you have some other reason, you don't really need to wait for them. All that's necessary to implement JXTA instant messaging and presence is already there.

Cheers Emil

Cheers Nick

From: Emil Ivov <emil.ivov@gmail.com> Reply-To: dev@sip-communicator.dev.java.net To: dev@sip-communicator.dev.java.net Subject: [sip-comm-dev] Volunteers for implementing JXTA support? (was: jxta and address book) Date: Sun, 23 Apr 2006 06:16:31 +0200

Hey Nick, all

Took me a while huh :). Well they say - better late than never, so here goes.

buzz lightyear wrote:

I just suddenly realised that for jxta, a peerid is
also needed for each peer. This is the ID you use
to contact another peer with.

All protocols in the SIP Communicator are represented
by the ProtocolProviderService package. The package
contains an interface called ContactID. This interface is implemented by the various protocols in
the way they seem fit or in other words they could just as well wrap the implementation around a PeerID.

Incidentally, I am using the opportunity to ask whether someone out there would be a volunteer to start an implementation of the ProtocolProviderService over JXTA? I personally think
that this would be a very cool thing to do!

Don't be shy! Step forward!

Cheers Emil

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

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 7.5 today! http://join.msn.com/messenger/overview

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

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 7.5 today! http://join.msn.com/messenger/overview

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

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

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

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters

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

_________________________________________________________________ Be
the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters

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


#19

My interest really is with implementing standard protocols, such as sip, over jxta.

Well things like this would involve much research. If this is what
interests you could surely do it. It's open source we're dealing with
here so you are free to do whatever you like. Integrating it in the
sip-communicator source tree might not come quickly since research
matters like this require much evaluation and testing. Yet you don't
really need it to be a part of the project right from the beginning in order
to work on it. It's your call.

Sorry, disagree on this one - re. SIP - if you already can have two sip clients talking to each other, one stream dealing with the sip protocol and the other with rtp, then all that is required is a jxta wrapper. If the sip code was already in cvs (for 1.0) then I would demonstrate!

You can already use myjxta2 for video, audio and messaging via jxta.

Now that's something else and it could easily fit the sip-comm as it is
since it could easily be implemented in a separate jxta bundle and plug
nicely in the OSGI. If I understand correctly this is something you
are not interested in doing though so it's a pity.

I don't like the idea of this as it's not standards based. Consider the instance where you're trying to set up a conference call between jxta clients and pstn sip-based clients (routed via a server), what a nightmare trying to control it!

If you manage to get the sip protocol into cvs within the next week or so, then I will certainly use it as the underlying library - otherwise I guess my only option is to use the pre-1.0 trunk and fork it.

Nick

···

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

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


#20

Sorry, disagree on this one - re. SIP - if you already can have two sip clients talking to each other, one stream dealing with the sip protocol and the other with rtp, then all that is required is a jxta wrapper. If the sip code was already in cvs (for 1.0) then I would demonstrate!

I didn't quite understand what is it that you don't agree with.

I don't like the idea of this as it's not standards based. Consider the instance where you're trying to set up a conference call between jxta clients and pstn sip-based clients (routed via a server), what a
nightmare trying to control it!

I guess I've not been clear enough .... not to mention the fact that
there is no
documentation on protocol providers at all so I imagine how easy it is
to become frustrated. I apologize for the situation.

ProtocolProviders are meant to encapsulate instant messaging and
telephony protocols. One provider encapsulates one protocol. One
provider would only establish connections with other clients of the
_same_ protocol or protocol variation.

Hence encapsulating jxta in a protocol provider would mean that the only
connections this protocol provider is going to establish would be with
other clients that support the same kind of jxta instant messaging and
telephony. If some of these clients turns out to be a SIP or a PSTN
gateway then they will be the ones to do whatever controlling there is
to do. In any case this is outside the scope of the SIP Communicator.

Now of course this is only the common case. One day someone might
very well want to provide a SIP implementation of the ProtocolProvider
service that would use jxta sockets. This is perfectly acceptable and it
will be up to the implementor to decide what kinds of peers it would
support.

If you manage to get the sip protocol into cvs within the next week or so, then I will certainly use it as the underlying library - otherwise I guess my only option is to use the pre-1.0 trunk and fork
it.

Unfortunately I don't think there's any chance of this happening next
week so you could go ahead and use pre1.0 code.

Hope this answers your questions.

Good luck

Emil