[sip-comm-dev] [PATCH] Google Talk Wizard


#1

As alluded in the description of the previous patch introducing AbstractProtocolProviderService, the major goal was creating an AccountRegistrationWizard visualizing itself as creating Google Talk accounts though it internally creates a Jabber account.

The attached google-talk-wizard.patch introduces such an implementation that uses strings (located in the same .properties file as the Jabber ones but using the prefix "googletalk.") and images (well, the images aren't provided because I don't know where to get such but they should be placed in resources/images/protocol/googletalk with the file names the same as in resources/images/protocol/jabber) specific to Google Talk. The implementation is introduced as part of jabberaccregwizz in order to be able to extend JabberAccountRegistrationWizard. Further customizations to GoogleTalkAccountRegistrationWizard in order to make it less generic than the Jabber super are to be applied at a later time after mutual understanding with respect to what they should be.

Regards,
Lubo

google-talk-wizard.patch (283 KB)


#2

Hi Lubo. I made a free media directory
<http://www.atagar.com/freeMedia/>where you can find liberally
licensed icons and images (ie, safe to use in
our projects). DeleketSets has some nice Google Talk images but I'm not sure
if this would be problematic due to trademarks (anyone else have an idea?).
If that's problematic then there's a plethora of more generic icons to work
from. As for Jabber both NuoveXT and CrystalSVG have options.

This next part is generic food for thought (not really about the patch).
Does anyone have an opinion about having one of the initialization wizard's
questions be about the user's experience which determines the verbosity and
coddling in the interface? For instance:
a. Be kind, I'm new.
  Verbose explanations and lots of wizards. Perhaps some how-tos for account
setup with various services.
b. Bah, I'm a veteran IM user.
  Normal user, probably transferring accounts. Help with common mistakes
(such as GTalk vs Jabber).
c. How dare you insult me so! I eat and breath this stuff. Bring on the
pain.
  Skimmed down interface for people who know what they're doing (proxies,
ports, SSL and all the other acronyms that make the common user cringe up
front and available).

Pardon the flair, I just had some coffee. My thinking is just that for
issues like the confusion between GTalk and Jabber it really depends on the
target audience. If the experience level was globally available then any UI
component (including plugins) could provide an appearance and behavior more
appropriate to the user in situations like this. The idea seems worth
exploring... any thoughts? -Damian

···

On Sun, Jun 22, 2008 at 11:17 AM, Lubomir Marinov <lubomir.marinov@gmail.com> wrote:

As alluded in the description of the previous patch introducing
AbstractProtocolProviderService, the major goal was creating an
AccountRegistrationWizard visualizing itself as creating Google Talk
accounts though it internally creates a Jabber account.

The attached google-talk-wizard.patch introduces such an implementation
that uses strings (located in the same .properties file as the Jabber ones
but using the prefix "googletalk.") and images (well, the images aren't
provided because I don't know where to get such but they should be placed in
resources/images/protocol/googletalk with the file names the same as in
resources/images/protocol/jabber) specific to Google Talk. The
implementation is introduced as part of jabberaccregwizz in order to be able
to extend JabberAccountRegistrationWizard. Further customizations to
GoogleTalkAccountRegistrationWizard in order to make it less generic than
the Jabber super are to be applied at a later time after mutual
understanding with respect to what they should be.

Regards,
Lubo

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


#3

The previous patch was considered inappropriate because it implemented
a Google Talk-specific AccountRegistrationWizard in jabberaccregwizz
and thus made it impossible to have the two wizards distributed as
standalone.

The attached patch modifies the Jabber protocol implementation in a
fashion similar to the SIP protocol implementation in order to take
into account the PROTOCOL_ICON_PATH property of the accountProperties
and not rely on a single hardcoded value. In doing so, it prepares the
ground for a Google Talk-specific wizard (in fact, any wizard willing
to create a Jabber account) which wants to have its own status icons.

Regards,
Lubo

Allow-PROTOCOL_ICON_PATH-override-in-Jabber.patch (34.6 KB)

···

On Sun, Jun 22, 2008 at 9:17 PM, Lubomir Marinov <lubomir.marinov@gmail.com> wrote:

As alluded in the description of the previous patch introducing
AbstractProtocolProviderService, the major goal was creating an
AccountRegistrationWizard visualizing itself as creating Google Talk
accounts though it internally creates a Jabber account.

The attached google-talk-wizard.patch introduces such an implementation that
uses strings (located in the same .properties file as the Jabber ones but
using the prefix "googletalk.") and images (well, the images aren't provided
because I don't know where to get such but they should be placed in
resources/images/protocol/googletalk with the file names the same as in
resources/images/protocol/jabber) specific to Google Talk. The
implementation is introduced as part of jabberaccregwizz in order to be able
to extend JabberAccountRegistrationWizard. Further customizations to
GoogleTalkAccountRegistrationWizard in order to make it less generic than
the Jabber super are to be applied at a later time after mutual
understanding with respect to what they should be.

Regards,
Lubo


#4

The attached googletalkaccregwizz.zip and googletalkaccregwizz.patch
(just includes the bundle googletalkaccregwizz in build.xml and in
felix.client.run.properties) build on the support added by
Allow-PROTOCOL_ICON_PATH-override-in-Jabber.patch and implement the
Google Talk-specific account registration wizard which uses the Jabber
protocol while visualizing itself and the account created by it as
Google Talk.

The wizard in question resides in its own bundle and doesn't extend
the Jabber account registration wizard. The only downside I noticed is
that the protocol and status icons have to be included in the Jabber
protocol implementation bundle because
ProtocolProviderFactory.PROTOCOL_ICON_PATH only specifies the path and
not the bundle that contains it.

Regards,
Lubo

googletalkaccregwizz.zip (37.2 KB)

googletalkaccregwizz.patch (2.59 KB)

···

On Tue, Jun 24, 2008 at 5:21 PM, Lubomir Marinov <lubomir.marinov@gmail.com> wrote:

The previous patch was considered inappropriate because it implemented
a Google Talk-specific AccountRegistrationWizard in jabberaccregwizz
and thus made it impossible to have the two wizards distributed as
standalone.

The attached patch modifies the Jabber protocol implementation in a
fashion similar to the SIP protocol implementation in order to take
into account the PROTOCOL_ICON_PATH property of the accountProperties
and not rely on a single hardcoded value. In doing so, it prepares the
ground for a Google Talk-specific wizard (in fact, any wizard willing
to create a Jabber account) which wants to have its own status icons.

Regards,
Lubo

On Sun, Jun 22, 2008 at 9:17 PM, Lubomir Marinov > <lubomir.marinov@gmail.com> wrote:

As alluded in the description of the previous patch introducing
AbstractProtocolProviderService, the major goal was creating an
AccountRegistrationWizard visualizing itself as creating Google Talk
accounts though it internally creates a Jabber account.

The attached google-talk-wizard.patch introduces such an implementation that
uses strings (located in the same .properties file as the Jabber ones but
using the prefix "googletalk.") and images (well, the images aren't provided
because I don't know where to get such but they should be placed in
resources/images/protocol/googletalk with the file names the same as in
resources/images/protocol/jabber) specific to Google Talk. The
implementation is introduced as part of jabberaccregwizz in order to be able
to extend JabberAccountRegistrationWizard. Further customizations to
GoogleTalkAccountRegistrationWizard in order to make it less generic than
the Jabber super are to be applied at a later time after mutual
understanding with respect to what they should be.

Regards,
Lubo


#5

Dear Emil,

Thank you for you help. Your pointer to ClassLoader#getResource()
indeed allowed me to make the Google Talk account registration wizard
fully-contained in its own bundle.

The attached Allow-PROTOCOL_ICON_PATH-override-in-Jabber.patch enables
the Jabber implementation to respect the PROTOCOL_ICON_PATH property
and acquire the protocol and status icons from the path in question
even if it's an URL (what ClassLoader.getResource() returns).

The attached googletalkaccregwizz.zip contains the Google Talk account
registration wizard and should be expanded inside
src/net/java/sip/communicator/plugin/ to create a googletalkaccregwizz
folder hierarchy. The patch googletalkaccregwizz.patch just enables
the building and the execution of the new wizard.

On a side note, because I had to modify two loadIcon methods which
were pretty much the same, I noticed the issues described bellow.
Please note that there're multiple loadIcon methods with relatively
the same implementations and their number is probably in the tens.

The loadIcon methods I'm referring to roughly look as follows:

InputStream is = AClassName.class.getClassLoader().getResourceAsStream(name);
byte[] bytes = new byte[is.available()];
is.read(bytes);

The first issue that jumps to mind is that InputStrem#available() has
nothing to do with the number of bytes one will have to read from the
InputStream - it's the number of bytes one can read from the stream
without blocking. From experience, I can tell you that the result of
InputStream#available() can return 0 even for non-empty files on the
local file system. Consequently, I think the above isn't the way one
wants to read the whole contents of a file.

The second issue is that the InputStream isn't closed once the reading
is finished. I don't know the specifics of the InputStream returned by
ClassLoader#getResourceAsStream() but I coudn't find a notice in the
Javadoc related to the safety of not closing it. For what it's worth,
it's publicly-recognized good practice to explicitly close
InputStreams as soon as possible.

Best regards,
Lubo

Allow-PROTOCOL_ICON_PATH-override-in-Jabber.patch (36.8 KB)

googletalkaccregwizz.zip (31.7 KB)

googletalkaccregwizz.patch (2.21 KB)

···

2008/7/1 Emil Ivov <emcho@sip-communicator.org>:

Hey Lubo,

I haven't had a chance to say this so far but I really like the idea of
having a gmail-ized jabber version so I am happy to know someone is
working on it.

Concerning your patch, as per our offline discussion, I think that we
are almost there but there one or two things still left to cover:

Lubomir Marinov написа:

The only downside I noticed is
that the protocol and status icons have to be included in the Jabber
protocol implementation bundle because
ProtocolProviderFactory.PROTOCOL_ICON_PATH only specifies the path and
not the bundle that contains it.

Yup I agree that's a shame and we'd better make sure that a plugin can
do anything they want with a protocol. I believe we can handle this
issue if using URLs. getClassLoader().getResource() should give you a
felix-ized URL that would look like this

bundle://<bundle-id>:<class-path-idx>/path/to/resource

Can you try and see if this would work in your case?

Cheers
Emil

Regards,
Lubo

On Tue, Jun 24, 2008 at 5:21 PM, Lubomir Marinov >> <lubomir.marinov@gmail.com> wrote:

The previous patch was considered inappropriate because it implemented
a Google Talk-specific AccountRegistrationWizard in jabberaccregwizz
and thus made it impossible to have the two wizards distributed as
standalone.

The attached patch modifies the Jabber protocol implementation in a
fashion similar to the SIP protocol implementation in order to take
into account the PROTOCOL_ICON_PATH property of the accountProperties
and not rely on a single hardcoded value. In doing so, it prepares the
ground for a Google Talk-specific wizard (in fact, any wizard willing
to create a Jabber account) which wants to have its own status icons.

Regards,
Lubo

On Sun, Jun 22, 2008 at 9:17 PM, Lubomir Marinov >>> <lubomir.marinov@gmail.com> wrote:

As alluded in the description of the previous patch introducing
AbstractProtocolProviderService, the major goal was creating an
AccountRegistrationWizard visualizing itself as creating Google Talk
accounts though it internally creates a Jabber account.

The attached google-talk-wizard.patch introduces such an implementation that
uses strings (located in the same .properties file as the Jabber ones but
using the prefix "googletalk.") and images (well, the images aren't provided
because I don't know where to get such but they should be placed in
resources/images/protocol/googletalk with the file names the same as in
resources/images/protocol/jabber) specific to Google Talk. The
implementation is introduced as part of jabberaccregwizz in order to be able
to extend JabberAccountRegistrationWizard. Further customizations to
GoogleTalkAccountRegistrationWizard in order to make it less generic than
the Jabber super are to be applied at a later time after mutual
understanding with respect to what they should be.

Regards,
Lubo

------------------------------------------------------------------------

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

Hey Lubo,

Was about to commit your patch but discovered a few minor discrepancies
that are worth addressing.

1. Could you please move your icons and strings to the resources
hierarchy? We've been playing with resources recently so I apologise for
  the confusion. Icons, for example, could live in
resource/images/protocol/googletalk

2. It would probably be a good idea to change the names of your classes
and fields/variables so that they would be named after GoogleTalk
instead of Jabber.

3. The same for icon names.

4. Do you really need JabberServerChooserDialog.java and
JabberNewAccountDialog.java? GoogleTalk accounts would only work with
one server. You may however want to place a link to
https://www.google.com/accounts/NewAccount somewhere in there.

5. Can you please sign your name in the @author field?

Guess this is all. Will come back to you if anything else pops up.

Cheers
Emil

Lubomir Marinov написа:

···

Dear Emil,

Thank you for you help. Your pointer to ClassLoader#getResource()
indeed allowed me to make the Google Talk account registration wizard
fully-contained in its own bundle.

The attached Allow-PROTOCOL_ICON_PATH-override-in-Jabber.patch enables
the Jabber implementation to respect the PROTOCOL_ICON_PATH property
and acquire the protocol and status icons from the path in question
even if it's an URL (what ClassLoader.getResource() returns).

The attached googletalkaccregwizz.zip contains the Google Talk account
registration wizard and should be expanded inside
src/net/java/sip/communicator/plugin/ to create a googletalkaccregwizz
folder hierarchy. The patch googletalkaccregwizz.patch just enables
the building and the execution of the new wizard.

On a side note, because I had to modify two loadIcon methods which
were pretty much the same, I noticed the issues described bellow.
Please note that there're multiple loadIcon methods with relatively
the same implementations and their number is probably in the tens.

The loadIcon methods I'm referring to roughly look as follows:

InputStream is = AClassName.class.getClassLoader().getResourceAsStream(name);
byte[] bytes = new byte[is.available()];
is.read(bytes);

The first issue that jumps to mind is that InputStrem#available() has
nothing to do with the number of bytes one will have to read from the
InputStream - it's the number of bytes one can read from the stream
without blocking. From experience, I can tell you that the result of
InputStream#available() can return 0 even for non-empty files on the
local file system. Consequently, I think the above isn't the way one
wants to read the whole contents of a file.

The second issue is that the InputStream isn't closed once the reading
is finished. I don't know the specifics of the InputStream returned by
ClassLoader#getResourceAsStream() but I coudn't find a notice in the
Javadoc related to the safety of not closing it. For what it's worth,
it's publicly-recognized good practice to explicitly close
InputStreams as soon as possible.

Best regards,
Lubo

2008/7/1 Emil Ivov <emcho@sip-communicator.org>:

Hey Lubo,

I haven't had a chance to say this so far but I really like the idea of
having a gmail-ized jabber version so I am happy to know someone is
working on it.

Concerning your patch, as per our offline discussion, I think that we
are almost there but there one or two things still left to cover:

Lubomir Marinov написа:

The only downside I noticed is
that the protocol and status icons have to be included in the Jabber
protocol implementation bundle because
ProtocolProviderFactory.PROTOCOL_ICON_PATH only specifies the path and
not the bundle that contains it.

Yup I agree that's a shame and we'd better make sure that a plugin can
do anything they want with a protocol. I believe we can handle this
issue if using URLs. getClassLoader().getResource() should give you a
felix-ized URL that would look like this

bundle://<bundle-id>:<class-path-idx>/path/to/resource

Can you try and see if this would work in your case?

Cheers
Emil

Regards,
Lubo

On Tue, Jun 24, 2008 at 5:21 PM, Lubomir Marinov >>> <lubomir.marinov@gmail.com> wrote:

The previous patch was considered inappropriate because it implemented
a Google Talk-specific AccountRegistrationWizard in jabberaccregwizz
and thus made it impossible to have the two wizards distributed as
standalone.

The attached patch modifies the Jabber protocol implementation in a
fashion similar to the SIP protocol implementation in order to take
into account the PROTOCOL_ICON_PATH property of the accountProperties
and not rely on a single hardcoded value. In doing so, it prepares the
ground for a Google Talk-specific wizard (in fact, any wizard willing
to create a Jabber account) which wants to have its own status icons.

Regards,
Lubo

On Sun, Jun 22, 2008 at 9:17 PM, Lubomir Marinov >>>> <lubomir.marinov@gmail.com> wrote:

As alluded in the description of the previous patch introducing
AbstractProtocolProviderService, the major goal was creating an
AccountRegistrationWizard visualizing itself as creating Google Talk
accounts though it internally creates a Jabber account.

The attached google-talk-wizard.patch introduces such an implementation that
uses strings (located in the same .properties file as the Jabber ones but
using the prefix "googletalk.") and images (well, the images aren't provided
because I don't know where to get such but they should be placed in
resources/images/protocol/googletalk with the file names the same as in
resources/images/protocol/jabber) specific to Google Talk. The
implementation is introduced as part of jabberaccregwizz in order to be able
to extend JabberAccountRegistrationWizard. Further customizations to
GoogleTalkAccountRegistrationWizard in order to make it less generic than
the Jabber super are to be applied at a later time after mutual
understanding with respect to what they should be.

Regards,
Lubo

------------------------------------------------------------------------

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


#7

Dear Emil,

Thank you for the attention and patience!

The attached patches and their associated ZIP files try to address the
issues you've described.

1-Allow-PROTOCOL_ICON_PATH-override-in-Jabber.patch is modified as
follows in comparison to the last version sent in this thread:

- Adds @author Lubomir Marinov in the files that have added fields or
methods or contain non-trivial changes.

- Changes the references to the images in
resources/images/protocol/jabber to be based on "status" or "logo" and
not "jabber". For example, jabber48x48.png is renamed to logo48x48.png
(because it's not a status icon) and jabber16x16-online.png is changed
to status16x16.png.

1-Allow-PROTOCOL_ICON_PATH-override-in-Jabber.zip contains the renamed
images mentioned above. Note though that jabber16x16-invisible.png and
jabber16x16-na.png in resources/images/protocol/jabber/ are not
referenced anywhere and, consequently, are left unchanged.

2-googletalkaccregwizz.zip and 2-googletalkaccregwizz.patch strive to
implement the rest of the requests.

I hope the latest modifications will meet your requirement.

Thank you,
Lubo

1-Allow-PROTOCOL_ICON_PATH-override-in-Jabber.patch (38.6 KB)

1-Allow-PROTOCOL_ICON_PATH-override-in-Jabber.zip (10.7 KB)

2-googletalkaccregwizz.patch (2.19 KB)

2-googletalkaccregwizz.zip (25.1 KB)

···

On Mon, Jul 7, 2008 at 10:55 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Lubo,

Was about to commit your patch but discovered a few minor discrepancies
that are worth addressing.

1. Could you please move your icons and strings to the resources
hierarchy? We've been playing with resources recently so I apologise for
the confusion. Icons, for example, could live in
resource/images/protocol/googletalk

2. It would probably be a good idea to change the names of your classes
and fields/variables so that they would be named after GoogleTalk
instead of Jabber.

3. The same for icon names.

4. Do you really need JabberServerChooserDialog.java and
JabberNewAccountDialog.java? GoogleTalk accounts would only work with
one server. You may however want to place a link to
https://www.google.com/accounts/NewAccount somewhere in there.

5. Can you please sign your name in the @author field?

Guess this is all. Will come back to you if anything else pops up.

Cheers
Emil

Lubomir Marinov написа:

Dear Emil,

Thank you for you help. Your pointer to ClassLoader#getResource()
indeed allowed me to make the Google Talk account registration wizard
fully-contained in its own bundle.

The attached Allow-PROTOCOL_ICON_PATH-override-in-Jabber.patch enables
the Jabber implementation to respect the PROTOCOL_ICON_PATH property
and acquire the protocol and status icons from the path in question
even if it's an URL (what ClassLoader.getResource() returns).

The attached googletalkaccregwizz.zip contains the Google Talk account
registration wizard and should be expanded inside
src/net/java/sip/communicator/plugin/ to create a googletalkaccregwizz
folder hierarchy. The patch googletalkaccregwizz.patch just enables
the building and the execution of the new wizard.

On a side note, because I had to modify two loadIcon methods which
were pretty much the same, I noticed the issues described bellow.
Please note that there're multiple loadIcon methods with relatively
the same implementations and their number is probably in the tens.

The loadIcon methods I'm referring to roughly look as follows:

InputStream is = AClassName.class.getClassLoader().getResourceAsStream(name);
byte[] bytes = new byte[is.available()];
is.read(bytes);

The first issue that jumps to mind is that InputStrem#available() has
nothing to do with the number of bytes one will have to read from the
InputStream - it's the number of bytes one can read from the stream
without blocking. From experience, I can tell you that the result of
InputStream#available() can return 0 even for non-empty files on the
local file system. Consequently, I think the above isn't the way one
wants to read the whole contents of a file.

The second issue is that the InputStream isn't closed once the reading
is finished. I don't know the specifics of the InputStream returned by
ClassLoader#getResourceAsStream() but I coudn't find a notice in the
Javadoc related to the safety of not closing it. For what it's worth,
it's publicly-recognized good practice to explicitly close
InputStreams as soon as possible.

Best regards,
Lubo

2008/7/1 Emil Ivov <emcho@sip-communicator.org>:

Hey Lubo,

I haven't had a chance to say this so far but I really like the idea of
having a gmail-ized jabber version so I am happy to know someone is
working on it.

Concerning your patch, as per our offline discussion, I think that we
are almost there but there one or two things still left to cover:

Lubomir Marinov написа:

The only downside I noticed is
that the protocol and status icons have to be included in the Jabber
protocol implementation bundle because
ProtocolProviderFactory.PROTOCOL_ICON_PATH only specifies the path and
not the bundle that contains it.

Yup I agree that's a shame and we'd better make sure that a plugin can
do anything they want with a protocol. I believe we can handle this
issue if using URLs. getClassLoader().getResource() should give you a
felix-ized URL that would look like this

bundle://<bundle-id>:<class-path-idx>/path/to/resource

Can you try and see if this would work in your case?

Cheers
Emil

Regards,
Lubo

On Tue, Jun 24, 2008 at 5:21 PM, Lubomir Marinov >>>> <lubomir.marinov@gmail.com> wrote:

The previous patch was considered inappropriate because it implemented
a Google Talk-specific AccountRegistrationWizard in jabberaccregwizz
and thus made it impossible to have the two wizards distributed as
standalone.

The attached patch modifies the Jabber protocol implementation in a
fashion similar to the SIP protocol implementation in order to take
into account the PROTOCOL_ICON_PATH property of the accountProperties
and not rely on a single hardcoded value. In doing so, it prepares the
ground for a Google Talk-specific wizard (in fact, any wizard willing
to create a Jabber account) which wants to have its own status icons.

Regards,
Lubo

On Sun, Jun 22, 2008 at 9:17 PM, Lubomir Marinov >>>>> <lubomir.marinov@gmail.com> wrote:

As alluded in the description of the previous patch introducing
AbstractProtocolProviderService, the major goal was creating an
AccountRegistrationWizard visualizing itself as creating Google Talk
accounts though it internally creates a Jabber account.

The attached google-talk-wizard.patch introduces such an implementation that
uses strings (located in the same .properties file as the Jabber ones but
using the prefix "googletalk.") and images (well, the images aren't provided
because I don't know where to get such but they should be placed in
resources/images/protocol/googletalk with the file names the same as in
resources/images/protocol/jabber) specific to Google Talk. The
implementation is introduced as part of jabberaccregwizz in order to be able
to extend JabberAccountRegistrationWizard. Further customizations to
GoogleTalkAccountRegistrationWizard in order to make it less generic than
the Jabber super are to be applied at a later time after mutual
understanding with respect to what they should be.

Regards,
Lubo

------------------------------------------------------------------------

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


#8

Hey Lubo,

Thanks for taking my comments into account. I have just applied and
ack-ed your contribution. I am also currently using it and it works well!

Just one detail left to fix:

All gtalk states have the same icon. We actually use the same modifiers
for all protocols so you can simply borrow the mini icons from from
jabber and apply them to the gtalk wizard.

Cheers
Emil

Lubomir Marinov написа:

···

Dear Emil,

Thank you for the attention and patience!

The attached patches and their associated ZIP files try to address the
issues you've described.

1-Allow-PROTOCOL_ICON_PATH-override-in-Jabber.patch is modified as
follows in comparison to the last version sent in this thread:

- Adds @author Lubomir Marinov in the files that have added fields or
methods or contain non-trivial changes.

- Changes the references to the images in
resources/images/protocol/jabber to be based on "status" or "logo" and
not "jabber". For example, jabber48x48.png is renamed to logo48x48.png
(because it's not a status icon) and jabber16x16-online.png is changed
to status16x16.png.

1-Allow-PROTOCOL_ICON_PATH-override-in-Jabber.zip contains the renamed
images mentioned above. Note though that jabber16x16-invisible.png and
jabber16x16-na.png in resources/images/protocol/jabber/ are not
referenced anywhere and, consequently, are left unchanged.

2-googletalkaccregwizz.zip and 2-googletalkaccregwizz.patch strive to
implement the rest of the requests.

I hope the latest modifications will meet your requirement.

Thank you,
Lubo

On Mon, Jul 7, 2008 at 10:55 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Lubo,

Was about to commit your patch but discovered a few minor discrepancies
that are worth addressing.

1. Could you please move your icons and strings to the resources
hierarchy? We've been playing with resources recently so I apologise for
the confusion. Icons, for example, could live in
resource/images/protocol/googletalk

2. It would probably be a good idea to change the names of your classes
and fields/variables so that they would be named after GoogleTalk
instead of Jabber.

3. The same for icon names.

4. Do you really need JabberServerChooserDialog.java and
JabberNewAccountDialog.java? GoogleTalk accounts would only work with
one server. You may however want to place a link to
https://www.google.com/accounts/NewAccount somewhere in there.

5. Can you please sign your name in the @author field?

Guess this is all. Will come back to you if anything else pops up.

Cheers
Emil

Lubomir Marinov написа:

Dear Emil,

Thank you for you help. Your pointer to ClassLoader#getResource()
indeed allowed me to make the Google Talk account registration wizard
fully-contained in its own bundle.

The attached Allow-PROTOCOL_ICON_PATH-override-in-Jabber.patch enables
the Jabber implementation to respect the PROTOCOL_ICON_PATH property
and acquire the protocol and status icons from the path in question
even if it's an URL (what ClassLoader.getResource() returns).

The attached googletalkaccregwizz.zip contains the Google Talk account
registration wizard and should be expanded inside
src/net/java/sip/communicator/plugin/ to create a googletalkaccregwizz
folder hierarchy. The patch googletalkaccregwizz.patch just enables
the building and the execution of the new wizard.

On a side note, because I had to modify two loadIcon methods which
were pretty much the same, I noticed the issues described bellow.
Please note that there're multiple loadIcon methods with relatively
the same implementations and their number is probably in the tens.

The loadIcon methods I'm referring to roughly look as follows:

InputStream is = AClassName.class.getClassLoader().getResourceAsStream(name);
byte[] bytes = new byte[is.available()];
is.read(bytes);

The first issue that jumps to mind is that InputStrem#available() has
nothing to do with the number of bytes one will have to read from the
InputStream - it's the number of bytes one can read from the stream
without blocking. From experience, I can tell you that the result of
InputStream#available() can return 0 even for non-empty files on the
local file system. Consequently, I think the above isn't the way one
wants to read the whole contents of a file.

The second issue is that the InputStream isn't closed once the reading
is finished. I don't know the specifics of the InputStream returned by
ClassLoader#getResourceAsStream() but I coudn't find a notice in the
Javadoc related to the safety of not closing it. For what it's worth,
it's publicly-recognized good practice to explicitly close
InputStreams as soon as possible.

Best regards,
Lubo

2008/7/1 Emil Ivov <emcho@sip-communicator.org>:

Hey Lubo,

I haven't had a chance to say this so far but I really like the idea of
having a gmail-ized jabber version so I am happy to know someone is
working on it.

Concerning your patch, as per our offline discussion, I think that we
are almost there but there one or two things still left to cover:

Lubomir Marinov написа:

The only downside I noticed is
that the protocol and status icons have to be included in the Jabber
protocol implementation bundle because
ProtocolProviderFactory.PROTOCOL_ICON_PATH only specifies the path and
not the bundle that contains it.

Yup I agree that's a shame and we'd better make sure that a plugin can
do anything they want with a protocol. I believe we can handle this
issue if using URLs. getClassLoader().getResource() should give you a
felix-ized URL that would look like this

bundle://<bundle-id>:<class-path-idx>/path/to/resource

Can you try and see if this would work in your case?

Cheers
Emil

Regards,
Lubo

On Tue, Jun 24, 2008 at 5:21 PM, Lubomir Marinov >>>>> <lubomir.marinov@gmail.com> wrote:

The previous patch was considered inappropriate because it implemented
a Google Talk-specific AccountRegistrationWizard in jabberaccregwizz
and thus made it impossible to have the two wizards distributed as
standalone.

The attached patch modifies the Jabber protocol implementation in a
fashion similar to the SIP protocol implementation in order to take
into account the PROTOCOL_ICON_PATH property of the accountProperties
and not rely on a single hardcoded value. In doing so, it prepares the
ground for a Google Talk-specific wizard (in fact, any wizard willing
to create a Jabber account) which wants to have its own status icons.

Regards,
Lubo

On Sun, Jun 22, 2008 at 9:17 PM, Lubomir Marinov >>>>>> <lubomir.marinov@gmail.com> wrote:

As alluded in the description of the previous patch introducing
AbstractProtocolProviderService, the major goal was creating an
AccountRegistrationWizard visualizing itself as creating Google Talk
accounts though it internally creates a Jabber account.

The attached google-talk-wizard.patch introduces such an implementation that
uses strings (located in the same .properties file as the Jabber ones but
using the prefix "googletalk.") and images (well, the images aren't provided
because I don't know where to get such but they should be placed in
resources/images/protocol/googletalk with the file names the same as in
resources/images/protocol/jabber) specific to Google Talk. The
implementation is introduced as part of jabberaccregwizz in order to be able
to extend JabberAccountRegistrationWizard. Further customizations to
GoogleTalkAccountRegistrationWizard in order to make it less generic than
the Jabber super are to be applied at a later time after mutual
understanding with respect to what they should be.

Regards,
Lubo

------------------------------------------------------------------------

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

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


#9

Emil,

This e-mail message carries a ZIP attachment containing updates status
icons (which should be expanded in
resources/images/protocol/googletalk).

The only remaining status icon is status16x16-connecting.gif because I
still don't know how to create a GIF.

Regards,
Lubo

googletalk-status-icons.zip (4.04 KB)

···

On Thu, Jul 10, 2008 at 4:34 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Lubo,

Thanks for taking my comments into account. I have just applied and
ack-ed your contribution. I am also currently using it and it works well!

Just one detail left to fix:

All gtalk states have the same icon. We actually use the same modifiers
for all protocols so you can simply borrow the mini icons from from
jabber and apply them to the gtalk wizard.

Cheers
Emil

Lubomir Marinov написа:

Dear Emil,

Thank you for the attention and patience!

The attached patches and their associated ZIP files try to address the
issues you've described.

1-Allow-PROTOCOL_ICON_PATH-override-in-Jabber.patch is modified as
follows in comparison to the last version sent in this thread:

- Adds @author Lubomir Marinov in the files that have added fields or
methods or contain non-trivial changes.

- Changes the references to the images in
resources/images/protocol/jabber to be based on "status" or "logo" and
not "jabber". For example, jabber48x48.png is renamed to logo48x48.png
(because it's not a status icon) and jabber16x16-online.png is changed
to status16x16.png.

1-Allow-PROTOCOL_ICON_PATH-override-in-Jabber.zip contains the renamed
images mentioned above. Note though that jabber16x16-invisible.png and
jabber16x16-na.png in resources/images/protocol/jabber/ are not
referenced anywhere and, consequently, are left unchanged.

2-googletalkaccregwizz.zip and 2-googletalkaccregwizz.patch strive to
implement the rest of the requests.

I hope the latest modifications will meet your requirement.

Thank you,
Lubo

On Mon, Jul 7, 2008 at 10:55 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Lubo,

Was about to commit your patch but discovered a few minor discrepancies
that are worth addressing.

1. Could you please move your icons and strings to the resources
hierarchy? We've been playing with resources recently so I apologise for
the confusion. Icons, for example, could live in
resource/images/protocol/googletalk

2. It would probably be a good idea to change the names of your classes
and fields/variables so that they would be named after GoogleTalk
instead of Jabber.

3. The same for icon names.

4. Do you really need JabberServerChooserDialog.java and
JabberNewAccountDialog.java? GoogleTalk accounts would only work with
one server. You may however want to place a link to
https://www.google.com/accounts/NewAccount somewhere in there.

5. Can you please sign your name in the @author field?

Guess this is all. Will come back to you if anything else pops up.

Cheers
Emil

Lubomir Marinov написа:

Dear Emil,

Thank you for you help. Your pointer to ClassLoader#getResource()
indeed allowed me to make the Google Talk account registration wizard
fully-contained in its own bundle.

The attached Allow-PROTOCOL_ICON_PATH-override-in-Jabber.patch enables
the Jabber implementation to respect the PROTOCOL_ICON_PATH property
and acquire the protocol and status icons from the path in question
even if it's an URL (what ClassLoader.getResource() returns).

The attached googletalkaccregwizz.zip contains the Google Talk account
registration wizard and should be expanded inside
src/net/java/sip/communicator/plugin/ to create a googletalkaccregwizz
folder hierarchy. The patch googletalkaccregwizz.patch just enables
the building and the execution of the new wizard.

On a side note, because I had to modify two loadIcon methods which
were pretty much the same, I noticed the issues described bellow.
Please note that there're multiple loadIcon methods with relatively
the same implementations and their number is probably in the tens.

The loadIcon methods I'm referring to roughly look as follows:

InputStream is = AClassName.class.getClassLoader().getResourceAsStream(name);
byte[] bytes = new byte[is.available()];
is.read(bytes);

The first issue that jumps to mind is that InputStrem#available() has
nothing to do with the number of bytes one will have to read from the
InputStream - it's the number of bytes one can read from the stream
without blocking. From experience, I can tell you that the result of
InputStream#available() can return 0 even for non-empty files on the
local file system. Consequently, I think the above isn't the way one
wants to read the whole contents of a file.

The second issue is that the InputStream isn't closed once the reading
is finished. I don't know the specifics of the InputStream returned by
ClassLoader#getResourceAsStream() but I coudn't find a notice in the
Javadoc related to the safety of not closing it. For what it's worth,
it's publicly-recognized good practice to explicitly close
InputStreams as soon as possible.

Best regards,
Lubo

2008/7/1 Emil Ivov <emcho@sip-communicator.org>:

Hey Lubo,

I haven't had a chance to say this so far but I really like the idea of
having a gmail-ized jabber version so I am happy to know someone is
working on it.

Concerning your patch, as per our offline discussion, I think that we
are almost there but there one or two things still left to cover:

Lubomir Marinov написа:

The only downside I noticed is
that the protocol and status icons have to be included in the Jabber
protocol implementation bundle because
ProtocolProviderFactory.PROTOCOL_ICON_PATH only specifies the path and
not the bundle that contains it.

Yup I agree that's a shame and we'd better make sure that a plugin can
do anything they want with a protocol. I believe we can handle this
issue if using URLs. getClassLoader().getResource() should give you a
felix-ized URL that would look like this

bundle://<bundle-id>:<class-path-idx>/path/to/resource

Can you try and see if this would work in your case?

Cheers
Emil

Regards,
Lubo

On Tue, Jun 24, 2008 at 5:21 PM, Lubomir Marinov >>>>>> <lubomir.marinov@gmail.com> wrote:

The previous patch was considered inappropriate because it implemented
a Google Talk-specific AccountRegistrationWizard in jabberaccregwizz
and thus made it impossible to have the two wizards distributed as
standalone.

The attached patch modifies the Jabber protocol implementation in a
fashion similar to the SIP protocol implementation in order to take
into account the PROTOCOL_ICON_PATH property of the accountProperties
and not rely on a single hardcoded value. In doing so, it prepares the
ground for a Google Talk-specific wizard (in fact, any wizard willing
to create a Jabber account) which wants to have its own status icons.

Regards,
Lubo

On Sun, Jun 22, 2008 at 9:17 PM, Lubomir Marinov >>>>>>> <lubomir.marinov@gmail.com> wrote:

As alluded in the description of the previous patch introducing
AbstractProtocolProviderService, the major goal was creating an
AccountRegistrationWizard visualizing itself as creating Google Talk
accounts though it internally creates a Jabber account.

The attached google-talk-wizard.patch introduces such an implementation that
uses strings (located in the same .properties file as the Jabber ones but
using the prefix "googletalk.") and images (well, the images aren't provided
because I don't know where to get such but they should be placed in
resources/images/protocol/googletalk with the file names the same as in
resources/images/protocol/jabber) specific to Google Talk. The
implementation is introduced as part of jabberaccregwizz in order to be able
to extend JabberAccountRegistrationWizard. Further customizations to
GoogleTalkAccountRegistrationWizard in order to make it less generic than
the Jabber super are to be applied at a later time after mutual
understanding with respect to what they should be.

Regards,
Lubo

------------------------------------------------------------------------

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

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


#10

Applied, committed and acked.

Thanks!
Emil

Lubomir Marinov написа:

···

Emil,

This e-mail message carries a ZIP attachment containing updates status
icons (which should be expanded in
resources/images/protocol/googletalk).

The only remaining status icon is status16x16-connecting.gif because I
still don't know how to create a GIF.

Regards,
Lubo

On Thu, Jul 10, 2008 at 4:34 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Lubo,

Thanks for taking my comments into account. I have just applied and
ack-ed your contribution. I am also currently using it and it works well!

Just one detail left to fix:

All gtalk states have the same icon. We actually use the same modifiers
for all protocols so you can simply borrow the mini icons from from
jabber and apply them to the gtalk wizard.

Cheers
Emil

Lubomir Marinov написа:

Dear Emil,

Thank you for the attention and patience!

The attached patches and their associated ZIP files try to address the
issues you've described.

1-Allow-PROTOCOL_ICON_PATH-override-in-Jabber.patch is modified as
follows in comparison to the last version sent in this thread:

- Adds @author Lubomir Marinov in the files that have added fields or
methods or contain non-trivial changes.

- Changes the references to the images in
resources/images/protocol/jabber to be based on "status" or "logo" and
not "jabber". For example, jabber48x48.png is renamed to logo48x48.png
(because it's not a status icon) and jabber16x16-online.png is changed
to status16x16.png.

1-Allow-PROTOCOL_ICON_PATH-override-in-Jabber.zip contains the renamed
images mentioned above. Note though that jabber16x16-invisible.png and
jabber16x16-na.png in resources/images/protocol/jabber/ are not
referenced anywhere and, consequently, are left unchanged.

2-googletalkaccregwizz.zip and 2-googletalkaccregwizz.patch strive to
implement the rest of the requests.

I hope the latest modifications will meet your requirement.

Thank you,
Lubo

On Mon, Jul 7, 2008 at 10:55 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

Hey Lubo,

Was about to commit your patch but discovered a few minor discrepancies
that are worth addressing.

1. Could you please move your icons and strings to the resources
hierarchy? We've been playing with resources recently so I apologise for
the confusion. Icons, for example, could live in
resource/images/protocol/googletalk

2. It would probably be a good idea to change the names of your classes
and fields/variables so that they would be named after GoogleTalk
instead of Jabber.

3. The same for icon names.

4. Do you really need JabberServerChooserDialog.java and
JabberNewAccountDialog.java? GoogleTalk accounts would only work with
one server. You may however want to place a link to
https://www.google.com/accounts/NewAccount somewhere in there.

5. Can you please sign your name in the @author field?

Guess this is all. Will come back to you if anything else pops up.

Cheers
Emil

Lubomir Marinov написа:

Dear Emil,

Thank you for you help. Your pointer to ClassLoader#getResource()
indeed allowed me to make the Google Talk account registration wizard
fully-contained in its own bundle.

The attached Allow-PROTOCOL_ICON_PATH-override-in-Jabber.patch enables
the Jabber implementation to respect the PROTOCOL_ICON_PATH property
and acquire the protocol and status icons from the path in question
even if it's an URL (what ClassLoader.getResource() returns).

The attached googletalkaccregwizz.zip contains the Google Talk account
registration wizard and should be expanded inside
src/net/java/sip/communicator/plugin/ to create a googletalkaccregwizz
folder hierarchy. The patch googletalkaccregwizz.patch just enables
the building and the execution of the new wizard.

On a side note, because I had to modify two loadIcon methods which
were pretty much the same, I noticed the issues described bellow.
Please note that there're multiple loadIcon methods with relatively
the same implementations and their number is probably in the tens.

The loadIcon methods I'm referring to roughly look as follows:

InputStream is = AClassName.class.getClassLoader().getResourceAsStream(name);
byte[] bytes = new byte[is.available()];
is.read(bytes);

The first issue that jumps to mind is that InputStrem#available() has
nothing to do with the number of bytes one will have to read from the
InputStream - it's the number of bytes one can read from the stream
without blocking. From experience, I can tell you that the result of
InputStream#available() can return 0 even for non-empty files on the
local file system. Consequently, I think the above isn't the way one
wants to read the whole contents of a file.

The second issue is that the InputStream isn't closed once the reading
is finished. I don't know the specifics of the InputStream returned by
ClassLoader#getResourceAsStream() but I coudn't find a notice in the
Javadoc related to the safety of not closing it. For what it's worth,
it's publicly-recognized good practice to explicitly close
InputStreams as soon as possible.

Best regards,
Lubo

2008/7/1 Emil Ivov <emcho@sip-communicator.org>:

Hey Lubo,

I haven't had a chance to say this so far but I really like the idea of
having a gmail-ized jabber version so I am happy to know someone is
working on it.

Concerning your patch, as per our offline discussion, I think that we
are almost there but there one or two things still left to cover:

Lubomir Marinov написа:

The only downside I noticed is
that the protocol and status icons have to be included in the Jabber
protocol implementation bundle because
ProtocolProviderFactory.PROTOCOL_ICON_PATH only specifies the path and
not the bundle that contains it.

Yup I agree that's a shame and we'd better make sure that a plugin can
do anything they want with a protocol. I believe we can handle this
issue if using URLs. getClassLoader().getResource() should give you a
felix-ized URL that would look like this

bundle://<bundle-id>:<class-path-idx>/path/to/resource

Can you try and see if this would work in your case?

Cheers
Emil

Regards,
Lubo

On Tue, Jun 24, 2008 at 5:21 PM, Lubomir Marinov >>>>>>> <lubomir.marinov@gmail.com> wrote:

The previous patch was considered inappropriate because it implemented
a Google Talk-specific AccountRegistrationWizard in jabberaccregwizz
and thus made it impossible to have the two wizards distributed as
standalone.

The attached patch modifies the Jabber protocol implementation in a
fashion similar to the SIP protocol implementation in order to take
into account the PROTOCOL_ICON_PATH property of the accountProperties
and not rely on a single hardcoded value. In doing so, it prepares the
ground for a Google Talk-specific wizard (in fact, any wizard willing
to create a Jabber account) which wants to have its own status icons.

Regards,
Lubo

On Sun, Jun 22, 2008 at 9:17 PM, Lubomir Marinov >>>>>>>> <lubomir.marinov@gmail.com> wrote:

As alluded in the description of the previous patch introducing
AbstractProtocolProviderService, the major goal was creating an
AccountRegistrationWizard visualizing itself as creating Google Talk
accounts though it internally creates a Jabber account.

The attached google-talk-wizard.patch introduces such an implementation that
uses strings (located in the same .properties file as the Jabber ones but
using the prefix "googletalk.") and images (well, the images aren't provided
because I don't know where to get such but they should be placed in
resources/images/protocol/googletalk with the file names the same as in
resources/images/protocol/jabber) specific to Google Talk. The
implementation is introduced as part of jabberaccregwizz in order to be able
to extend JabberAccountRegistrationWizard. Further customizations to
GoogleTalkAccountRegistrationWizard in order to make it less generic than
the Jabber super are to be applied at a later time after mutual
understanding with respect to what they should be.

Regards,
Lubo

------------------------------------------------------------------------

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

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