[jitsi-dev] [jitsi-commits] [jitsi/jitsi] 311d75: Moves verify certificate dialog in separate servic...


#1

Hi devs,

discussing and checking possibilities for moving the android project to
github we are now trying to clear the jitsi bundles so we can use them in
android and skip the source syncing.

Changing certificate service is one of them, more to follow.

I have compared the sources from jitsi and jitsi-android which we used to
sync and here is what I have in my todo list:

- in net.java.sip.communicator.impl.certificate a dialog is shown, already
changed.
- net.java.sip.communicator.impl.credentialsstorage a dialog is shown
- net.java.sip.communicator.impl.dns to move the config form in separate
bundle
- net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,
using java.awt.Toolkit use reflection to load it.
- operation set desktop sharing was removed from jabber and sip because of
java.awt.event.MouseEvent and java.awt.event.KeyEvent
- net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
sasl mechanisum does not compile in android
- check why white board operation set is commented and will jabber provider
bundle will normally operation under android with it
- in ProtocolProviderServiceJabberImpl we are pre-configuring some smack
services as they are normally loaded from the jar file.
- in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile cause of
SSLSocketFactory
- in SipStackSharing we have changed the path name of the factory to org.
jitsi.gov.nist, because of the renaming of jsip package, must check will it
work after adding the protocol bundle
- LoggingUtils separate the configuration form
- NotificationManager - some image loading which we must remove in order to
use the plugin in android
- UIContact and UIGroup use SIPCommButton (from desktoputil) - this
one Yanahas upcoming change which will fix it
- service.httputil.HttpUtils - doesn't compile in android, using it will
not be possible
- icon in FileUtils, maybe separate as service
- android's UtilActivator adds JavaUtilLoggingConfig

This are the notes and changes we need to do in order to reuse
jitsibundles in android.
Also I'm currently testing a change in the build system in order to speed
up development/test process.

Comments and help are welcome :slight_smile:

Thanks
damencho

···

On Thu, May 16, 2013 at 10:40 AM, Damian Minkov <damencho@jitsi.org> wrote:

  Branch: refs/heads/master
  Home: https://github.com/jitsi/jitsi
  Commit: 311d7512c909466e9c662481a5af7198717d8a8c

https://github.com/jitsi/jitsi/commit/311d7512c909466e9c662481a5af7198717d8a8c
  Author: Damian Minkov <damencho@jitsi.org>
  Date: 2013-05-16 (Thu, 16 May 2013)

  Changed paths:
    M
src/net/java/sip/communicator/impl/certificate/CertificateServiceImpl.java
    M
src/net/java/sip/communicator/impl/certificate/CertificateVerificationActivator.java
    R
src/net/java/sip/communicator/impl/certificate/VerifyCertificateDialog.java
    M
src/net/java/sip/communicator/plugin/desktoputil/DesktopUtilActivator.java
    A
src/net/java/sip/communicator/plugin/desktoputil/VerifyCertificateDialogImpl.java
    M
src/net/java/sip/communicator/plugin/desktoputil/desktoputil.manifest.mf
    A
src/net/java/sip/communicator/service/certificate/VerifyCertificateDialogService.java

  Log Message:
  -----------
  Moves verify certificate dialog in separate service in order to use the
certificate service in android.

_______________________________________________
commits mailing list
commits@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/commits


#2

Hi,

Hi devs,

discussing and checking possibilities for moving the android project to github we are now trying to clear the jitsi bundles so we can use them in android and skip the source syncing.

Sounds great!

Changing certificate service is one of them, more to follow.

I have compared the sources from jitsi and jitsi-android which we used to sync and here is what I have in my todo list:

- in net.java.sip.communicator.impl.certificate a dialog is shown, already changed.
- net.java.sip.communicator.impl.credentialsstorage a dialog is shown
- net.java.sip.communicator.impl.dns to move the config form in separate bundle
- net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl, using java.awt.Toolkit use reflection to load it.
- operation set desktop sharing was removed from jabber and sip because of java.awt.event.MouseEvent and java.awt.event.KeyEvent
- net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
sasl mechanisum does not compile in android
- check why white board operation set is commented and will jabber provider bundle will normally operation under android with it
- in ProtocolProviderServiceJabberImpl we are pre-configuring some smack services as they are normally loaded from the jar file.
- in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile cause of SSLSocketFactory
- in SipStackSharing we have changed the path name of the factory to org.jitsi.gov.nist, because of the renaming of jsip package, must check will it work after adding the protocol bundle
- LoggingUtils separate the configuration form
- NotificationManager - some image loading which we must remove in order to use the plugin in android
- UIContact and UIGroup use SIPCommButton (from desktoputil) - this one Yana has upcoming change which will fix it
- service.httputil.HttpUtils - doesn't compile in android, using it will not be possible
- icon in FileUtils, maybe separate as service
- android's UtilActivator adds JavaUtilLoggingConfig

This are the notes and changes we need to do in order to reuse jitsi bundles in android.

All changes look doable.

Also I'm currently testing a change in the build system in order to speed up development/test process.

That would be really great! I'm currently working on the Android version and it takes quite a lot of time to build the apk.

Cheers,
Yana

···

On May 16, 2013, at 11:42 AM, Damian Minkov <damencho@jitsi.org> wrote:

Comments and help are welcome :slight_smile:

Thanks
damencho

On Thu, May 16, 2013 at 10:40 AM, Damian Minkov <damencho@jitsi.org> wrote:
  Branch: refs/heads/master
  Home: https://github.com/jitsi/jitsi
  Commit: 311d7512c909466e9c662481a5af7198717d8a8c
      https://github.com/jitsi/jitsi/commit/311d7512c909466e9c662481a5af7198717d8a8c
  Author: Damian Minkov <damencho@jitsi.org>
  Date: 2013-05-16 (Thu, 16 May 2013)

  Changed paths:
    M src/net/java/sip/communicator/impl/certificate/CertificateServiceImpl.java
    M src/net/java/sip/communicator/impl/certificate/CertificateVerificationActivator.java
    R src/net/java/sip/communicator/impl/certificate/VerifyCertificateDialog.java
    M src/net/java/sip/communicator/plugin/desktoputil/DesktopUtilActivator.java
    A src/net/java/sip/communicator/plugin/desktoputil/VerifyCertificateDialogImpl.java
    M src/net/java/sip/communicator/plugin/desktoputil/desktoputil.manifest.mf
    A src/net/java/sip/communicator/service/certificate/VerifyCertificateDialogService.java

  Log Message:
  -----------
  Moves verify certificate dialog in separate service in order to use the certificate service in android.

_______________________________________________
commits mailing list
commits@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/commits

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

I have compared the sources from jitsi and jitsi-android which we used to
sync and here is what I have in my todo list:

- in net.java.sip.communicator.impl.certificate a dialog is shown, already
changed.

That looks very good and is probably the blueprint for further changes.

- net.java.sip.communicator.impl.credentialsstorage a dialog is shown

Similar to the certificate service?

- net.java.sip.communicator.impl.dns to move the config form in separate
bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will also
change. For the time being, I think you could just leave out the complete
dns impl package.

-

net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,

using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService needs to
be implemented differently for Android?

- operation set desktop sharing was removed from jabber and sip because of
java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a jar
wouldn't be available on the desktop, it wouldn't matter as long as they're
not called. So as long as it isn't registered as an operation set, this
shouldn't matter.

- net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
sasl mechanisum does not compile in android

Smack for Android seems to import org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing. If we
do, loading it conditionally on the desktop or through reflection should be
possible.

- check why white board operation set is commented and will jabber

provider

bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely remove
the code?

- in ProtocolProviderServiceJabberImpl we are pre-configuring some smack
services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by subclassing it?

- in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile cause of
SSLSocketFactory

Um, why? It should be there...
http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point Android
decided to kind of drop support for httpcomponents and suggesting some other
method for HTTP requests (sorry, don't remember the class name)

- in SipStackSharing we have changed the path name of the factory to
org.jitsi.gov.nist, because of the renaming of jsip package, must check

will

it work after adding the protocol bundle
- LoggingUtils separate the configuration form

-> To plugin

- NotificationManager - some image loading which we must remove in order

to

use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for Android
(because I'm guessing that not all events are needed there).

- UIContact and UIGroup use SIPCommButton (from desktoputil) - this one

Yana

has upcoming change which will fix it
- service.httputil.HttpUtils - doesn't compile in android, using it will

not

be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

- icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used outside
of impl.gui.

- android's UtilActivator adds JavaUtilLoggingConfig

This are the notes and changes we need to do in order to reuse jitsi

bundles

in android.
Also I'm currently testing a change in the build system in order to speed

up

development/test process.

Comments and help are welcome :slight_smile:

Thanks
damencho

Ingo


#4

Hi,

more inline:

> I have compared the sources from jitsi and jitsi-android which we used to
> sync and here is what I have in my todo list:
>
> - in net.java.sip.communicator.impl.certificate a dialog is shown,
already
> changed.

That looks very good and is probably the blueprint for further changes.

> - net.java.sip.communicator.impl.credentialsstorage a dialog is shown

Similar to the certificate service?

Yep, already fixed.

> - net.java.sip.communicator.impl.dns to move the config form in separate
> bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will also
change. For the time being, I think you could just leave out the complete
dns impl package.

Also done that.

> -
net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,
> using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService needs to
be implemented differently for Android?

> - operation set desktop sharing was removed from jabber and sip because
of
> java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a jar
wouldn't be available on the desktop, it wouldn't matter as long as they're
not called. So as long as it isn't registered as an operation set, this
shouldn't matter.

Well loading some classes is failing currently cause of missing classes but
I'm currently on it.

> - net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
> sasl mechanisum does not compile in android

Smack for Android seems to import org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing. If we
do, loading it conditionally on the desktop or through reflection should be
possible.

Well it is used for some buggy xmpp servers ... well I'm also not sure how
to handle it,
maybe turn it off and enable it on demand with prop.

> - check why white board operation set is commented and will jabber
provider
> bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely remove
the code?

> - in ProtocolProviderServiceJabberImpl we are pre-configuring some smack
> services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by subclassing
it?

Yep I'm currently integrating protocol bundles and will test it (code
running only
under android).

> - in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile cause of
> SSLSocketFactory

Um, why? It should be there...

http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html<http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFactory.html>
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point Android
decided to kind of drop support for httpcomponents and suggesting some
other
method for HTTP requests (sorry, don't remember the class name)

Well the version differ, I currently get this error:
05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method
org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from method
net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct
method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init>
(Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V

Thanks
damencho

···

On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

> - in SipStackSharing we have changed the path name of the factory to
> org.jitsi.gov.nist, because of the renaming of jsip package, must check
will
> it work after adding the protocol bundle
> - LoggingUtils separate the configuration form

-> To plugin

> - NotificationManager - some image loading which we must remove in order
to
> use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for Android
(because I'm guessing that not all events are needed there).

> - UIContact and UIGroup use SIPCommButton (from desktoputil) - this one
Yana
> has upcoming change which will fix it
> - service.httputil.HttpUtils - doesn't compile in android, using it will
not
> be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

> - icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used
outside
of impl.gui.

> - android's UtilActivator adds JavaUtilLoggingConfig
>
> This are the notes and changes we need to do in order to reuse jitsi
bundles
> in android.
> Also I'm currently testing a change in the build system in order to speed
up
> development/test process.
>
> Comments and help are welcome :slight_smile:
>
> Thanks
> damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Hey Yana, Pawel,

we also need to discuss and the defaultresourcepack bundle. Cause the
source code is the same but in android we do not need the resources from
the desktop application.
Actually are we using that? Wasn't there a new resource service impl?

Regards
damencho

···

On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

more inline:

On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

> I have compared the sources from jitsi and jitsi-android which we used
to
> sync and here is what I have in my todo list:
>
> - in net.java.sip.communicator.impl.certificate a dialog is shown,
already
> changed.

That looks very good and is probably the blueprint for further changes.

> - net.java.sip.communicator.impl.credentialsstorage a dialog is shown

Similar to the certificate service?

Yep, already fixed.

> - net.java.sip.communicator.impl.dns to move the config form in separate
> bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will also
change. For the time being, I think you could just leave out the complete
dns impl package.

Also done that.

> -
net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,
> using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService needs to
be implemented differently for Android?

> - operation set desktop sharing was removed from jabber and sip because
of
> java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a jar
wouldn't be available on the desktop, it wouldn't matter as long as
they're
not called. So as long as it isn't registered as an operation set, this
shouldn't matter.

Well loading some classes is failing currently cause of missing classes
but I'm currently on it.

> - net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
> sasl mechanisum does not compile in android

Smack for Android seems to import org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing. If
we
do, loading it conditionally on the desktop or through reflection should
be
possible.

Well it is used for some buggy xmpp servers ... well I'm also not sure how
to handle it,
maybe turn it off and enable it on demand with prop.

> - check why white board operation set is commented and will jabber
provider
> bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely remove
the code?

> - in ProtocolProviderServiceJabberImpl we are pre-configuring some smack
> services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by subclassing
it?

Yep I'm currently integrating protocol bundles and will test it (code
running only
under android).

> - in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile cause of
> SSLSocketFactory

Um, why? It should be there...

http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html<http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFactory.html>
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point Android
decided to kind of drop support for httpcomponents and suggesting some
other
method for HTTP requests (sorry, don't remember the class name)

Well the version differ, I currently get this error:
05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method
org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from method
net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct
method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init>
(Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V

Thanks
damencho

> - in SipStackSharing we have changed the path name of the factory to
> org.jitsi.gov.nist, because of the renaming of jsip package, must check
will
> it work after adding the protocol bundle
> - LoggingUtils separate the configuration form

-> To plugin

> - NotificationManager - some image loading which we must remove in order
to
> use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for Android
(because I'm guessing that not all events are needed there).

> - UIContact and UIGroup use SIPCommButton (from desktoputil) - this one
Yana
> has upcoming change which will fix it
> - service.httputil.HttpUtils - doesn't compile in android, using it will
not
> be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

> - icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used
outside
of impl.gui.

> - android's UtilActivator adds JavaUtilLoggingConfig
>
> This are the notes and changes we need to do in order to reuse jitsi
bundles
> in android.
> Also I'm currently testing a change in the build system in order to
speed
up
> development/test process.
>
> Comments and help are welcome :slight_smile:
>
> Thanks
> damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#6

Hi Damian,

There's a different implementation for Android. You could have a look at org.jitsi.impl.androidresources.AndroidResourceServiceImpl, so it's safe to remove the other one for the Android project.

Cheers,
Yana

···

On May 18, 2013, at 3:29 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hey Yana, Pawel,

we also need to discuss and the defaultresourcepack bundle. Cause the source code is the same but in android we do not need the resources from the desktop application.
Actually are we using that? Wasn't there a new resource service impl?

Regards
damencho

On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org> wrote:
Hi,

more inline:

On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:
> I have compared the sources from jitsi and jitsi-android which we used to
> sync and here is what I have in my todo list:
>
> - in net.java.sip.communicator.impl.certificate a dialog is shown, already
> changed.

That looks very good and is probably the blueprint for further changes.

> - net.java.sip.communicator.impl.credentialsstorage a dialog is shown

Similar to the certificate service?

Yep, already fixed.

> - net.java.sip.communicator.impl.dns to move the config form in separate
> bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will also
change. For the time being, I think you could just leave out the complete
dns impl package.

Also done that.

> -
net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,
> using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService needs to
be implemented differently for Android?

> - operation set desktop sharing was removed from jabber and sip because of
> java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a jar
wouldn't be available on the desktop, it wouldn't matter as long as they're
not called. So as long as it isn't registered as an operation set, this
shouldn't matter.

Well loading some classes is failing currently cause of missing classes but I'm currently on it.

> - net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
> sasl mechanisum does not compile in android

Smack for Android seems to import org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing. If we
do, loading it conditionally on the desktop or through reflection should be
possible.

Well it is used for some buggy xmpp servers ... well I'm also not sure how to handle it,
maybe turn it off and enable it on demand with prop.

> - check why white board operation set is commented and will jabber
provider
> bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely remove
the code?

> - in ProtocolProviderServiceJabberImpl we are pre-configuring some smack
> services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by subclassing it?

Yep I'm currently integrating protocol bundles and will test it (code running only
under android).

> - in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile cause of
> SSLSocketFactory

Um, why? It should be there...
http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point Android
decided to kind of drop support for httpcomponents and suggesting some other
method for HTTP requests (sorry, don't remember the class name)

Well the version differ, I currently get this error:
05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from method net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init> (Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V

Thanks
damencho

> - in SipStackSharing we have changed the path name of the factory to
> org.jitsi.gov.nist, because of the renaming of jsip package, must check
will
> it work after adding the protocol bundle
> - LoggingUtils separate the configuration form

-> To plugin

> - NotificationManager - some image loading which we must remove in order
to
> use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for Android
(because I'm guessing that not all events are needed there).

> - UIContact and UIGroup use SIPCommButton (from desktoputil) - this one
Yana
> has upcoming change which will fix it
> - service.httputil.HttpUtils - doesn't compile in android, using it will
not
> be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

> - icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used outside
of impl.gui.

> - android's UtilActivator adds JavaUtilLoggingConfig
>
> This are the notes and changes we need to do in order to reuse jitsi
bundles
> in android.
> Also I'm currently testing a change in the build system in order to speed
up
> development/test process.
>
> Comments and help are welcome :slight_smile:
>
> Thanks
> damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

Isn't this thing only used for settings-defaults? If so, we wanted to move the default settings into the configurationService anyway...

Ingo

-- sent from my mobile

···

Le 18.05.2013 à 14:31, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hey Yana, Pawel,

we also need to discuss and the defaultresourcepack bundle. Cause the source code is the same but in android we do not need the resources from the desktop application.
Actually are we using that? Wasn't there a new resource service impl?

Regards
damencho

On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

more inline:

On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

> I have compared the sources from jitsi and jitsi-android which we used to
> sync and here is what I have in my todo list:
>
> - in net.java.sip.communicator.impl.certificate a dialog is shown, already
> changed.

That looks very good and is probably the blueprint for further changes.

> - net.java.sip.communicator.impl.credentialsstorage a dialog is shown

Similar to the certificate service?

Yep, already fixed.

> - net.java.sip.communicator.impl.dns to move the config form in separate
> bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will also
change. For the time being, I think you could just leave out the complete
dns impl package.

Also done that.

> -
net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,
> using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService needs to
be implemented differently for Android?

> - operation set desktop sharing was removed from jabber and sip because of
> java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a jar
wouldn't be available on the desktop, it wouldn't matter as long as they're
not called. So as long as it isn't registered as an operation set, this
shouldn't matter.

Well loading some classes is failing currently cause of missing classes but I'm currently on it.

> - net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
> sasl mechanisum does not compile in android

Smack for Android seems to import org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing. If we
do, loading it conditionally on the desktop or through reflection should be
possible.

Well it is used for some buggy xmpp servers ... well I'm also not sure how to handle it,
maybe turn it off and enable it on demand with prop.

> - check why white board operation set is commented and will jabber
provider
> bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely remove
the code?

> - in ProtocolProviderServiceJabberImpl we are pre-configuring some smack
> services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by subclassing it?

Yep I'm currently integrating protocol bundles and will test it (code running only
under android).

> - in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile cause of
> SSLSocketFactory

Um, why? It should be there...
http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point Android
decided to kind of drop support for httpcomponents and suggesting some other
method for HTTP requests (sorry, don't remember the class name)

Well the version differ, I currently get this error:
05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from method net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init> (Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V

Thanks
damencho

> - in SipStackSharing we have changed the path name of the factory to
> org.jitsi.gov.nist, because of the renaming of jsip package, must check
will
> it work after adding the protocol bundle
> - LoggingUtils separate the configuration form

-> To plugin

> - NotificationManager - some image loading which we must remove in order
to
> use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for Android
(because I'm guessing that not all events are needed there).

> - UIContact and UIGroup use SIPCommButton (from desktoputil) - this one
Yana
> has upcoming change which will fix it
> - service.httputil.HttpUtils - doesn't compile in android, using it will
not
> be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

> - icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used outside
of impl.gui.

> - android's UtilActivator adds JavaUtilLoggingConfig
>
> This are the notes and changes we need to do in order to reuse jitsi
bundles
> in android.
> Also I'm currently testing a change in the build system in order to speed
up
> development/test process.
>
> Comments and help are welcome :slight_smile:
>
> Thanks
> damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#8

Hi Damian,

Hey Yana, Pawel,

we also need to discuss and the defaultresourcepack bundle. Cause the source
code is the same but in android we do not need the resources from the
desktop application.
Actually are we using that? Wasn't there a new resource service impl?

Yes there is new resource service and it works with the
defaultresourcepack as well, but we have different resources
definition in src/resources folder. So there aren't all resources from
Jitsi, but only those that are used.

Regards,
Pawel

···

On Sat, May 18, 2013 at 2:29 PM, Damian Minkov <damencho@jitsi.org> wrote:

Regards
damencho

On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

more inline:

On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

> I have compared the sources from jitsi and jitsi-android which we used
> to
> sync and here is what I have in my todo list:
>
> - in net.java.sip.communicator.impl.certificate a dialog is shown,
> already
> changed.

That looks very good and is probably the blueprint for further changes.

> - net.java.sip.communicator.impl.credentialsstorage a dialog is shown

Similar to the certificate service?

Yep, already fixed.

> - net.java.sip.communicator.impl.dns to move the config form in
> separate
> bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will
also
change. For the time being, I think you could just leave out the complete
dns impl package.

Also done that.

> -
net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,
> using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService needs
to
be implemented differently for Android?

> - operation set desktop sharing was removed from jabber and sip because
> of
> java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a
jar
wouldn't be available on the desktop, it wouldn't matter as long as
they're
not called. So as long as it isn't registered as an operation set, this
shouldn't matter.

Well loading some classes is failing currently cause of missing classes
but I'm currently on it.

> -
> net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
> sasl mechanisum does not compile in android

Smack for Android seems to import
org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing. If
we
do, loading it conditionally on the desktop or through reflection should
be
possible.

Well it is used for some buggy xmpp servers ... well I'm also not sure how
to handle it,
maybe turn it off and enable it on demand with prop.

> - check why white board operation set is commented and will jabber
provider
> bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely remove
the code?

> - in ProtocolProviderServiceJabberImpl we are pre-configuring some
> smack
> services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by subclassing
it?

Yep I'm currently integrating protocol bundles and will test it (code
running only
under android).

> - in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile cause
> of
> SSLSocketFactory

Um, why? It should be there...

http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point Android
decided to kind of drop support for httpcomponents and suggesting some
other
method for HTTP requests (sorry, don't remember the class name)

Well the version differ, I currently get this error:
05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method
org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from method
net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct
method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init>
(Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V

Thanks
damencho

> - in SipStackSharing we have changed the path name of the factory to
> org.jitsi.gov.nist, because of the renaming of jsip package, must check
will
> it work after adding the protocol bundle
> - LoggingUtils separate the configuration form

-> To plugin

> - NotificationManager - some image loading which we must remove in
> order
to
> use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for Android
(because I'm guessing that not all events are needed there).

> - UIContact and UIGroup use SIPCommButton (from desktoputil) - this one
Yana
> has upcoming change which will fix it
> - service.httputil.HttpUtils - doesn't compile in android, using it
> will
not
> be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

> - icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used
outside
of impl.gui.

> - android's UtilActivator adds JavaUtilLoggingConfig
>
> This are the notes and changes we need to do in order to reuse jitsi
bundles
> in android.
> Also I'm currently testing a change in the build system in order to
> speed
up
> development/test process.
>
> Comments and help are welcome :slight_smile:
>
> Thanks
> damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#9

Hi Ingo,

no this bundle contains all the resources, like sounds, images, translates
...

Regards
damencho

···

On Sat, May 18, 2013 at 4:56 PM, Ingo Bauersachs <ingo@sip-communicator.org>wrote:

Isn't this thing only used for settings-defaults? If so, we wanted to move
the default settings into the configurationService anyway...

Ingo

-- sent from my mobile

Le 18.05.2013 à 14:31, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hey Yana, Pawel,

we also need to discuss and the defaultresourcepack bundle. Cause the
source code is the same but in android we do not need the resources from
the desktop application.
Actually are we using that? Wasn't there a new resource service impl?

Regards
damencho

On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org>wrote:

Hi,

more inline:

On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

> I have compared the sources from jitsi and jitsi-android which we used
to
> sync and here is what I have in my todo list:
>
> - in net.java.sip.communicator.impl.certificate a dialog is shown,
already
> changed.

That looks very good and is probably the blueprint for further changes.

> - net.java.sip.communicator.impl.credentialsstorage a dialog is shown

Similar to the certificate service?

Yep, already fixed.

> - net.java.sip.communicator.impl.dns to move the config form in
separate
> bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will
also
change. For the time being, I think you could just leave out the complete
dns impl package.

Also done that.

> -
net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,
> using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService needs
to
be implemented differently for Android?

> - operation set desktop sharing was removed from jabber and sip
because of
> java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a
jar
wouldn't be available on the desktop, it wouldn't matter as long as
they're
not called. So as long as it isn't registered as an operation set, this
shouldn't matter.

Well loading some classes is failing currently cause of missing classes
but I'm currently on it.

> -
net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
> sasl mechanisum does not compile in android

Smack for Android seems to import
org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing. If
we
do, loading it conditionally on the desktop or through reflection should
be
possible.

Well it is used for some buggy xmpp servers ... well I'm also not sure
how to handle it,
maybe turn it off and enable it on demand with prop.

> - check why white board operation set is commented and will jabber
provider
> bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely remove
the code?

> - in ProtocolProviderServiceJabberImpl we are pre-configuring some
smack
> services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by subclassing
it?

Yep I'm currently integrating protocol bundles and will test it (code
running only
under android).

> - in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile cause
of
> SSLSocketFactory

Um, why? It should be there...

http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html<http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFactory.html>
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point Android
decided to kind of drop support for httpcomponents and suggesting some
other
method for HTTP requests (sorry, don't remember the class name)

Well the version differ, I currently get this error:
05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method
org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from method
net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct
method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init>
(Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V

Thanks
damencho

> - in SipStackSharing we have changed the path name of the factory to
> org.jitsi.gov.nist, because of the renaming of jsip package, must check
will
> it work after adding the protocol bundle
> - LoggingUtils separate the configuration form

-> To plugin

> - NotificationManager - some image loading which we must remove in
order
to
> use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for Android
(because I'm guessing that not all events are needed there).

> - UIContact and UIGroup use SIPCommButton (from desktoputil) - this one
Yana
> has upcoming change which will fix it
> - service.httputil.HttpUtils - doesn't compile in android, using it
will
not
> be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

> - icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used
outside
of impl.gui.

> - android's UtilActivator adds JavaUtilLoggingConfig
>
> This are the notes and changes we need to do in order to reuse jitsi
bundles
> in android.
> Also I'm currently testing a change in the build system in order to
speed
up
> development/test process.
>
> Comments and help are welcome :slight_smile:
>
> Thanks
> damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#10

Yepp, thats clear. I was refering to its usage from within the protocols.

-- sent from my mobile

···

Le 18.05.2013 à 17:45, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hi Ingo,

no this bundle contains all the resources, like sounds, images, translates ...

Regards
damencho

On Sat, May 18, 2013 at 4:56 PM, Ingo Bauersachs <ingo@sip-communicator.org> wrote:

Isn't this thing only used for settings-defaults? If so, we wanted to move the default settings into the configurationService anyway...

Ingo

-- sent from my mobile

Le 18.05.2013 à 14:31, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hey Yana, Pawel,

we also need to discuss and the defaultresourcepack bundle. Cause the source code is the same but in android we do not need the resources from the desktop application.
Actually are we using that? Wasn't there a new resource service impl?

Regards
damencho

On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org> wrote:

Hi,

more inline:

On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

> I have compared the sources from jitsi and jitsi-android which we used to
> sync and here is what I have in my todo list:
>
> - in net.java.sip.communicator.impl.certificate a dialog is shown, already
> changed.

That looks very good and is probably the blueprint for further changes.

> - net.java.sip.communicator.impl.credentialsstorage a dialog is shown

Similar to the certificate service?

Yep, already fixed.

> - net.java.sip.communicator.impl.dns to move the config form in separate
> bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will also
change. For the time being, I think you could just leave out the complete
dns impl package.

Also done that.

> -
net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,
> using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService needs to
be implemented differently for Android?

> - operation set desktop sharing was removed from jabber and sip because of
> java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a jar
wouldn't be available on the desktop, it wouldn't matter as long as they're
not called. So as long as it isn't registered as an operation set, this
shouldn't matter.

Well loading some classes is failing currently cause of missing classes but I'm currently on it.

> - net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
> sasl mechanisum does not compile in android

Smack for Android seems to import org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing. If we
do, loading it conditionally on the desktop or through reflection should be
possible.

Well it is used for some buggy xmpp servers ... well I'm also not sure how to handle it,
maybe turn it off and enable it on demand with prop.

> - check why white board operation set is commented and will jabber
provider
> bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely remove
the code?

> - in ProtocolProviderServiceJabberImpl we are pre-configuring some smack
> services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by subclassing it?

Yep I'm currently integrating protocol bundles and will test it (code running only
under android).

> - in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile cause of
> SSLSocketFactory

Um, why? It should be there...
http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point Android
decided to kind of drop support for httpcomponents and suggesting some other
method for HTTP requests (sorry, don't remember the class name)

Well the version differ, I currently get this error:
05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from method net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init> (Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V

Thanks
damencho

> - in SipStackSharing we have changed the path name of the factory to
> org.jitsi.gov.nist, because of the renaming of jsip package, must check
will
> it work after adding the protocol bundle
> - LoggingUtils separate the configuration form

-> To plugin

> - NotificationManager - some image loading which we must remove in order
to
> use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for Android
(because I'm guessing that not all events are needed there).

> - UIContact and UIGroup use SIPCommButton (from desktoputil) - this one
Yana
> has upcoming change which will fix it
> - service.httputil.HttpUtils - doesn't compile in android, using it will
not
> be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

> - icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used outside
of impl.gui.

> - android's UtilActivator adds JavaUtilLoggingConfig
>
> This are the notes and changes we need to do in order to reuse jitsi
bundles
> in android.
> Also I'm currently testing a change in the build system in order to speed
up
> development/test process.
>
> Comments and help are welcome :slight_smile:
>
> Thanks
> damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#11

Well it is the notification service who is using it. This is the biggest
change left from the refactoring I'm currently doing.
Currently checking what is actually used there and will come up with
something on Monday and then it will be ready for the new repository.

-- sent from my mobile

···

On May 18, 2013 7:21 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:

Yepp, thats clear. I was refering to its usage from within the protocols.

-- sent from my mobile

Le 18.05.2013 à 17:45, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hi Ingo,

no this bundle contains all the resources, like sounds, images, translates
...

Regards
damencho

On Sat, May 18, 2013 at 4:56 PM, Ingo Bauersachs < > ingo@sip-communicator.org> wrote:

Isn't this thing only used for settings-defaults? If so, we wanted to
move the default settings into the configurationService anyway...

Ingo

-- sent from my mobile

Le 18.05.2013 à 14:31, "Damian Minkov" <damencho@jitsi.org> a écrit :

Hey Yana, Pawel,

we also need to discuss and the defaultresourcepack bundle. Cause the
source code is the same but in android we do not need the resources from
the desktop application.
Actually are we using that? Wasn't there a new resource service impl?

Regards
damencho

On Fri, May 17, 2013 at 12:00 PM, Damian Minkov <damencho@jitsi.org>wrote:

Hi,

more inline:

On Thu, May 16, 2013 at 11:16 PM, Ingo Bauersachs <ingo@jitsi.org>wrote:

> I have compared the sources from jitsi and jitsi-android which we
used to
> sync and here is what I have in my todo list:
>
> - in net.java.sip.communicator.impl.certificate a dialog is shown,
already
> changed.

That looks very good and is probably the blueprint for further changes.

> - net.java.sip.communicator.impl.credentialsstorage a dialog is shown

Similar to the certificate service?

Yep, already fixed.

> - net.java.sip.communicator.impl.dns to move the config form in
separate
> bundle

Yepp, into the plugin namespace.
I'm working on replacing the unbound native stuff and the config will
also
change. For the time being, I think you could just leave out the
complete
dns impl package.

Also done that.

> -

net.java.sip.communicator.impl.notification.SoundNotificationHandlerImpl,
> using java.awt.Toolkit use reflection to load it.

Not sure, but I'd have guessed that the whole NotificationService needs
to
be implemented differently for Android?

> - operation set desktop sharing was removed from jabber and sip
because of
> java.awt.event.MouseEvent and java.awt.event.KeyEvent

Not sure how this would work out for Android, but if some classes in a
jar
wouldn't be available on the desktop, it wouldn't matter as long as
they're
not called. So as long as it isn't registered as an operation set, this
shouldn't matter.

Well loading some classes is failing currently cause of missing classes
but I'm currently on it.

> -
net.java.sip.communicator.impl.protocol.jabber.LoginByPasswordStrategy
> sasl mechanisum does not compile in android

Smack for Android seems to import
org.apache.harmony.javax.security.sasl.*
I'm wondering if we still really need our own modified SaslMd5 thing.
If we
do, loading it conditionally on the desktop or through reflection
should be
possible.

Well it is used for some buggy xmpp servers ... well I'm also not sure
how to handle it,
maybe turn it off and enable it on demand with prop.

> - check why white board operation set is commented and will jabber
provider
> bundle will normally operation under android with it

I thought we dropped support for that long ago? Why not completely
remove
the code?

> - in ProtocolProviderServiceJabberImpl we are pre-configuring some
smack
> services as they are normally loaded from the jar file.

Could that be done somewhere outside of the PPS, or maybe by
subclassing it?

Yep I'm currently integrating protocol bundles and will test it (code
running only
under android).

> - in impl.protocol.sip.xcap.BaseHttpXCapClient does not compile cause
of
> SSLSocketFactory

Um, why? It should be there...

http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFac
tory.html<http://developer.android.com/reference/org/apache/http/conn/ssl/SSLSocketFactory.html>
Are we using some methods/constructors that are not yet there?
OTOH: we have a // TODO: move to HttpUtil.
I don't know what API level we want to support, but at some point
Android
decided to kind of drop support for httpcomponents and suggesting some
other
method for HTTP requests (sorry, don't remember the class name)

Well the version differ, I currently get this error:
05-17 11:50:20.032: INFO/dalvikvm(29858): Could not find method
org.apache.http.conn.ssl.SSLSocketFactory.<init>, referenced from method
net.java.sip.communicator.impl.protocol.sip.xcap.BaseHttpXCapClient.createHttpClient
05-17 11:50:20.032: WARN/dalvikvm(29858): VFY: unable to resolve direct
method 26444: Lorg/apache/http/conn/ssl/SSLSocketFactory;.<init>
(Ljavax/net/ssl/SSLContext;Lorg/apache/http/conn/ssl/X509HostnameVerifier;)V

Thanks
damencho

> - in SipStackSharing we have changed the path name of the factory to
> org.jitsi.gov.nist, because of the renaming of jsip package, must
check
will
> it work after adding the protocol bundle
> - LoggingUtils separate the configuration form

-> To plugin

> - NotificationManager - some image loading which we must remove in
order
to
> use the plugin in android

The NM is a complex beast. I'm wondering if we could split it up into
multiple classes or even provide a different implementation for Android
(because I'm guessing that not all events are needed there).

> - UIContact and UIGroup use SIPCommButton (from desktoputil) - this
one
Yana
> has upcoming change which will fix it
> - service.httputil.HttpUtils - doesn't compile in android, using it
will
not
> be possible

I'm wondering why (because Apache HttpClient should be available), but
otherwise same as with the XCAP stuff.

> - icon in FileUtils, maybe separate as service

Move the whole FileUtils into impl.gui.utils? It seems it's not used
outside
of impl.gui.

> - android's UtilActivator adds JavaUtilLoggingConfig
>
> This are the notes and changes we need to do in order to reuse jitsi
bundles
> in android.
> Also I'm currently testing a change in the build system in order to
speed
up
> development/test process.
>
> Comments and help are welcome :slight_smile:
>
> Thanks
> damencho

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev