[jitsi-dev] Re: [jitsi~svn:10326] Moves desktop related utils to plugin/desktoputils. Separates ComponentUt


#1

Whoooah... Could you please shortly explain what you did here a bit more detailed than in the commit message?
I guess that’s Android related?

Ingo

···

Log Message:
------------
Moves desktop related utils to plugin/desktoputils. Separates ComponentUtils
and WindowsUtils from general GuiUtils.


#2

Hey Ingo,

Sorry for not announcing the change earlier and thanks for bringing the subject on the mailing list!

I know it seems like a big change, but it's just what the commit says actually. I've tried to separate swing related utils from general utils and moved the swing and dns packages from util to plugin/desktoputil. This change should allow us to use some of the utility classes in the android version as well. There may be some more modifications like that (with smaller impact) in the upcoming weeks.

For now the whole dns package is also moved to the new desktoputil package, as it contained quite a lot of swing and awt related imports.

Hope this explains it better.
Yana

···

On Jan 25, 2013, at 1:14 AM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:

Whoooah... Could you please shortly explain what you did here a bit more detailed than in the commit message?
I guess that’s Android related?

Ingo

Log Message:
------------
Moves desktop related utils to plugin/desktoputils. Separates ComponentUtils
and WindowsUtils from general GuiUtils.


#3

Sorry for not announcing the change earlier and thanks for bringing the
subject on the mailing list!

I know it seems like a big change, but it's just what the commit says
actually. I've tried to separate swing related utils from general utils

and

moved the swing and dns packages from util to plugin/desktoputil. This

change

should allow us to use some of the utility classes in the android version

as

well. There may be some more modifications like that (with smaller impact)

in

the upcoming weeks.

Okay, no problem. I have some comments on the package structure in general,
but we can discuss that on the way to FOSDEM.

For now the whole dns package is also moved to the new desktoputil

package,

as it contained quite a lot of swing and awt related imports.

Caution with the dns package: There are some exception classes defined in
there which are used by all protocol implementations. I think as it stands
now, you cannot simply drop the whole dns package without breaking all the
protocols. The thing that's problematic in there should be only inside
ConfigurableDnssecResolver (and it's one of our classic mixtures of UI and
service code).

And, ideally, DNSSEC should be available on Android as well. Guess I should
start working on something to replace libunbound with managed code.
Different topic... :slight_smile:

Hope this explains it better.
Yana

Ingo


#4

Hey Ingo,

Sorry for not announcing the change earlier and thanks for bringing the
subject on the mailing list!

I know it seems like a big change, but it's just what the commit says
actually. I've tried to separate swing related utils from general utils

and

moved the swing and dns packages from util to plugin/desktoputil. This

change

should allow us to use some of the utility classes in the android version

as

well. There may be some more modifications like that (with smaller impact)

in

the upcoming weeks.

Okay, no problem. I have some comments on the package structure in general,
but we can discuss that on the way to FOSDEM.

For now the whole dns package is also moved to the new desktoputil

package,

as it contained quite a lot of swing and awt related imports.

Caution with the dns package: There are some exception classes defined in
there which are used by all protocol implementations. I think as it stands
now, you cannot simply drop the whole dns package without breaking all the
protocols.

Yep, you're right, it would be broken on android.

The thing that's problematic in there should be only inside
ConfigurableDnssecResolver (and it's one of our classic mixtures of UI and
service code).

I'm not familiar with the dns implementation at all, but after looking briefly into it I actually think that util wasn't the best place for the dns package and it would fit better in it's own plugin or service/impl. We should definitely move the UI related code in a separate plugin too. Does this make sense to you?

And, ideally, DNSSEC should be available on Android as well.

It would be cool yes :slight_smile:

Guess I should
start working on something to replace libunbound with managed code.
Different topic... :slight_smile:

Cheers,
Yana

···

On Jan 25, 2013, at 2:17 AM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:

Hope this explains it better.
Yana

Ingo


#5

But an interesting one all the same :). I am wondering if this would be
suitable for a student project. We could retry it on GSoC next year (if
they re-run it and if they accept us). I also have a few uni classes
scheduled for the near future so I could reach out to interested minds.

Unless, of course there's someone on this list willing to help with an impl?

Emil

···

On 25.01.13, 02:17, Ingo Bauersachs wrote:

And, ideally, DNSSEC should be available on Android as well. Guess I should
start working on something to replace libunbound with managed code.
Different topic... :slight_smile:

--
https://jitsi.org


#6

The thing that's problematic in there should be only inside
ConfigurableDnssecResolver (and it's one of our classic mixtures of UI

and

service code).

I'm not familiar with the dns implementation at all, but after looking
briefly into it I actually think that util wasn't the best place for the

dns

package and it would fit better in it's own plugin or service/impl. We

should

definitely move the UI related code in a separate plugin too. Does this

make

sense to you?

Yes it does, but it's not going to be as easy as other stuff. Think of
provisioning: we need to look up the URL, but at this time the UI is not yet
loaded.

Ingo


#7

And, ideally, DNSSEC should be available on Android as well. Guess I

should

start working on something to replace libunbound with managed code.
Different topic... :slight_smile:

But an interesting one all the same :). I am wondering if this would be
suitable for a student project. We could retry it on GSoC next year (if
they re-run it and if they accept us). I also have a few uni classes
scheduled for the near future so I could reach out to interested minds.

I think a student project is more appropriate. And we'd need to take a
second look at https://github.com/adamfisk/DNSSEC4J. Back when I first
looked at it, it wasn't mature and complete enough. Given that there hasn't
been any activity in a year beside the push to a Maven repository, I still
have some doubts.

Unless, of course there's someone on this list willing to help with an

impl?

Emil

Ingo

···

On 25.01.13, 02:17, Ingo Bauersachs wrote:


#8

Hey Ingo,

The thing that's problematic in there should be only inside
ConfigurableDnssecResolver (and it's one of our classic mixtures of UI

and

service code).

I'm not familiar with the dns implementation at all, but after looking
briefly into it I actually think that util wasn't the best place for the

dns

package and it would fit better in it's own plugin or service/impl. We

should

definitely move the UI related code in a separate plugin too. Does this

make

sense to you?

Yes it does, but it's not going to be as easy as other stuff. Think of
provisioning: we need to look up the URL, but at this time the UI is not yet
loaded.

Could you be more precise about the provisioning concern? Do you mean that separating the UI would be more difficult? Do you agree that the dns package would fit better in an service/impl structure, because I thought I can trying doing it this way.

Cheers,
Yana

···

On Jan 25, 2013, at 11:10 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Ingo


#9

Could you be more precise about the provisioning concern? Do you mean that
separating the UI would be more difficult? Do you agree that the dns

package

would fit better in an service/impl structure, because I thought I can

trying

doing it this way.

The provisioning was just an example. The concern is that DNS is one of the
earliest stuff we need to have running. In case something is wrong with a
domain name looked up, we need to show a popup/question way before the
actual UI is loaded. So separating it into service and impl makes only sense
in terms of having distinct UIs.

For a quick fix, I'd just move the two exception-classes to, e.g., the
package ...service.dns and leave the rest as is for the time being.

Cheers,
Yana

Ingo


#10

Yana, Ingo, and Emil,

Been following the thread on the DNS and DNSSEC, are you aware of the
dnsjava-2.1.4, last update 2013-01-04, I'm just now reviewing what changes
have been made, looks like an ECC algorithm was dropped and a couple of
ECDSA algorithms were added, going to dig into the code and see what I
might offer in support of the Jitsi project.

I joined the maillist sometime last year (Aug?) because your project was an
OSGI framework, and I was developing an ENUM with NAPTR/SRV's application
for the Google Android platform (Server/Client) and Jitsi looked like an
excellent fit.

Would like to help develop a DNS/DNSSEC Service/Impl for the desktop, but
with the intent of getting the Jitsi-Android app to an emulated/build
prototype. I'm using the Eclipse IDE environment for Android, but still
need to get Jitsi installed/configured for a 'dual' compile (probably this
weekend), Ant ???

As I stated earlier, been following about six(6) months now, and dug into
most of the code/structure that this dev@ maillist deals with... that's how
I've learned most past projects, i.e.- FRED (Free Registry for ENUMs and
Domains).

Let me know if I can participate in anyway, if only to review, but would
prefer to code and post, have enjoyed the camaraderie of exchanges, btw,
haven't seen much of Winona lately?

Lawrence

···

On Fri, Jan 25, 2013 at 5:59 AM, Ingo Bauersachs <ingo@jitsi.org> wrote:

> Could you be more precise about the provisioning concern? Do you mean
that
> separating the UI would be more difficult? Do you agree that the dns
package
> would fit better in an service/impl structure, because I thought I can
trying
> doing it this way.

The provisioning was just an example. The concern is that DNS is one of the
earliest stuff we need to have running. In case something is wrong with a
domain name looked up, we need to show a popup/question way before the
actual UI is loaded. So separating it into service and impl makes only
sense
in terms of having distinct UIs.

For a quick fix, I'd just move the two exception-classes to, e.g., the
package ...service.dns and leave the rest as is for the time being.

> Cheers,
> Yana

Ingo


#11

Hey Ingo,

I've tried to move the dns package in its own service and implementation packages and move the NetworkUtils back to the util package. It was quite tricky because in addition to the exception NetworkUtils was also calling directly the ParallelResolver. I had to add a ParallelResolver interface in the dns service and then register the implementation from the impl. I've also moved the dnsconfig plugin to the impl/dns package, which was a quick fix for the fact that it was using directly some dns implementation classes.

Could you please have a look, give it a try and tell me if this works for you? Do you see any problems that may occur with this solution?

Thanks!!
Yana

···

On Jan 25, 2013, at 1:59 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Could you be more precise about the provisioning concern? Do you mean that
separating the UI would be more difficult? Do you agree that the dns

package

would fit better in an service/impl structure, because I thought I can

trying

doing it this way.

The provisioning was just an example. The concern is that DNS is one of the
earliest stuff we need to have running. In case something is wrong with a
domain name looked up, we need to show a popup/question way before the
actual UI is loaded. So separating it into service and impl makes only sense
in terms of having distinct UIs.

For a quick fix, I'd just move the two exception-classes to, e.g., the
package ...service.dns and leave the rest as is for the time being.

Cheers,
Yana

Ingo


#12

Hey Lawrence

Been following the thread on the DNS and DNSSEC, are you aware of the
dnsjava-2.1.4, last update 2013-01-04, I'm just now reviewing what changes
have been made, looks like an ECC algorithm was dropped and a couple of

ECDSA

algorithms were added, going to dig into the code and see what I might

offer

in support of the Jitsi project.

No, I wasn't aware of it, thanks for the hint! Hell, I didn't even noticed
that he finally incorporated the hostname patch I sent back in December
2011.

I just looked into it and, as far as I can tell, the recent changes
introduced simply new signature algorithms. The problem is that the whole
lookup of all DNSSEC related records needed for verification are there, but
you need to manually verify, that is, you need to look up the RRSIG and DS
records up to the root all by yourself. And that is what libunbound is
currently doing for us and worth looking at in dnssec4j.

I joined the maillist sometime last year (Aug?) because your project was

an

OSGI framework, and I was developing an ENUM with NAPTR/SRV's application

for

the Google Android platform (Server/Client) and Jitsi looked like an
excellent fit.

Would like to help develop a DNS/DNSSEC Service/Impl for the desktop, but
with the intent of getting the Jitsi-Android app to an emulated/build
prototype. I'm using the Eclipse IDE environment for Android, but still

need

to get Jitsi installed/configured for a 'dual' compile (probably this
weekend), Ant ???

I don't know the Android build process either. Up till now this is still a
BlueJimp secret. I guess the first step to get DNSSEC on Android would be to
replace libunbound on the desktop version with something in pure Java, then
migrate it to Android (which ideally should just build).

As I stated earlier, been following about six(6) months now, and dug
into most of the code/structure that this dev@ maillist deals with...
that's how I've learned most past projects, i.e.- FRED (Free Registry
for ENUMs and Domains).

Let me know if I can participate in anyway, if only to review, but would
prefer to code and post, have enjoyed the camaraderie of exchanges, btw,
haven't seen much of Winona lately?

Sure, feel free to post any patches here. The developer documentation should
give you a jump start, especially [1], but I guess you know that already
given that you're following for some time.

Lawrence

Regards,
Ingo

[1] https://jitsi.org/Documentation/CodeConvention


#13

Hey

Well, the UI works again now with the two commits I've just made, but: The
JNI-library needs to be updated as well. While I can prepare the
source-files for that library, compilation of it for Mac is out of question
for me and for Windows at least going to be difficult.

Ouch. Had forgotten about the reverse dependency of that native stuff. C# is
so much easier...

Ingo

From: Yana Stamcheva [mailto:yana@jitsi.org]
Sent: Sonntag, 27. Januar 2013 19:54
To: dev@jitsi.java.net
Subject: [jitsi-dev] Re: [jitsi~svn:10326] Moves desktop related utils to
plugin/desktoputils. Separates ComponentUt

Hey Ingo,

I've tried to move the dns package in its own service and implementation
packages and move the NetworkUtils back to the util package. It was quite
tricky because in addition to the exception NetworkUtils was also calling
directly the ParallelResolver. I had to add a ParallelResolver interface

in

the dns service and then register the implementation from the impl. I've

also

moved the dnsconfig plugin to the impl/dns package, which was a quick fix

for

the fact that it was using directly some dns implementation classes.

Could you please have a look, give it a try and tell me if this works for
you? Do you see any problems that may occur with this solution?

Thanks!!
Yana

>> Could you be more precise about the provisioning concern? Do you mean

that

>> separating the UI would be more difficult? Do you agree that the dns
> package
>> would fit better in an service/impl structure, because I thought I can
> trying
>> doing it this way.
>
> The provisioning was just an example. The concern is that DNS is one of

the

> earliest stuff we need to have running. In case something is wrong with

a

···

-----Original Message-----
On Jan 25, 2013, at 1:59 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:
> domain name looked up, we need to show a popup/question way before the
> actual UI is loaded. So separating it into service and impl makes only
sense
> in terms of having distinct UIs.
>
> For a quick fix, I'd just move the two exception-classes to, e.g., the
> package ...service.dns and leave the rest as is for the time being.
>
>> Cheers,
>> Yana
>
> Ingo
>


#14

Ingo,

Thanks for the feedback/encouragement, will structure a support directive
for the Jitsi project that I can help with, will look into the dnssec4j.

Lawrence

···

On Fri, Jan 25, 2013 at 4:30 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Hey Lawrence

> Been following the thread on the DNS and DNSSEC, are you aware of the
> dnsjava-2.1.4, last update 2013-01-04, I'm just now reviewing what
changes
> have been made, looks like an ECC algorithm was dropped and a couple of
ECDSA
> algorithms were added, going to dig into the code and see what I might
offer
> in support of the Jitsi project.

No, I wasn't aware of it, thanks for the hint! Hell, I didn't even noticed
that he finally incorporated the hostname patch I sent back in December
2011.

I just looked into it and, as far as I can tell, the recent changes
introduced simply new signature algorithms. The problem is that the whole
lookup of all DNSSEC related records needed for verification are there, but
you need to manually verify, that is, you need to look up the RRSIG and DS
records up to the root all by yourself. And that is what libunbound is
currently doing for us and worth looking at in dnssec4j.

> I joined the maillist sometime last year (Aug?) because your project was
an
> OSGI framework, and I was developing an ENUM with NAPTR/SRV's application
for
> the Google Android platform (Server/Client) and Jitsi looked like an
> excellent fit.
>
>
> Would like to help develop a DNS/DNSSEC Service/Impl for the desktop, but
> with the intent of getting the Jitsi-Android app to an emulated/build
> prototype. I'm using the Eclipse IDE environment for Android, but still
need
> to get Jitsi installed/configured for a 'dual' compile (probably this
> weekend), Ant ???

I don't know the Android build process either. Up till now this is still a
BlueJimp secret. I guess the first step to get DNSSEC on Android would be
to
replace libunbound on the desktop version with something in pure Java, then
migrate it to Android (which ideally should just build).

> As I stated earlier, been following about six(6) months now, and dug
> into most of the code/structure that this dev@ maillist deals with...
> that's how I've learned most past projects, i.e.- FRED (Free Registry
> for ENUMs and Domains).
>
>
> Let me know if I can participate in anyway, if only to review, but would
> prefer to code and post, have enjoyed the camaraderie of exchanges, btw,
> haven't seen much of Winona lately?

Sure, feel free to post any patches here. The developer documentation
should
give you a jump start, especially [1], but I guess you know that already
given that you're following for some time.

> Lawrence

Regards,
Ingo

[1] https://jitsi.org/Documentation/CodeConvention


#15

Not much of a secret really: there's no build process for Android.
There's just a periodic merge of the Jitsi codebase into the Android branch.

Emil

···

On 26.01.13, 00:30, Ingo Bauersachs wrote:

I don't know the Android build process either. Up till now this is still a
BlueJimp secret.

--
https://jitsi.org