[jitsi-dev] Prerequisite patch for Android settings


#1

I need to change a littile bit more to reuse the registration classes,
as they are currently located in wizards plugin bundles. I thought
that SIPAccountRegistration and JabberAccountRegistration could be
available from some util or protocol packages.

AFAIK they are UI-independent, so you can move them to the protocol bundle(s).

Currently SecurityAccountRegistration and EncodingsRegistrationUtil
are in the util package(.util.wizard). Will this place will also be ok
for SIP and Jabber account registration objects ?

No, the util-package needs to stay protocol agnostic.

From logical point
of view maybe it fits more to some SIP and Jabber specific packages.

Definitely.

Regards,
Pawel

Regards,
Ingo


#2

I need to change a littile bit more to reuse the registration classes,
as they are currently located in wizards plugin bundles. I thought
that SIPAccountRegistration and JabberAccountRegistration could be
available from some util or protocol packages.

AFAIK they are UI-independent, so you can move them to the protocol bundle(s).

No, I'd rather you didn't do that. Protocol implementations are just
that and they are not supposed to be exported (which they would need to
be if they are to be accessed from the outside).

Тhese classes are only meant to serve as a backend for the swing
interface and a link to the account properties.

They are actually protocol agnostic to some extent so I suppose, if this
is really necessary, we could move part of them to the protocol service.

But yes, before we take a decision it would help to have your use case
explained a bit as Yana asked.

Emil

···

On 22.05.13, 12:13, Ingo Bauersachs wrote:

Currently SecurityAccountRegistration and EncodingsRegistrationUtil
are in the util package(.util.wizard). Will this place will also be ok
for SIP and Jabber account registration objects ?

No, the util-package needs to stay protocol agnostic.

From logical point
of view maybe it fits more to some SIP and Jabber specific packages.

Definitely.

Regards,
Pawel

Regards,
Ingo

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

--
https://jitsi.org


#3

I need to change a littile bit more to reuse the registration classes,
as they are currently located in wizards plugin bundles. I thought
that SIPAccountRegistration and JabberAccountRegistration could be
available from some util or protocol packages.

AFAIK they are UI-independent, so you can move them to the protocol bundle(s).

No, I'd rather you didn't do that. Protocol implementations are just
that and they are not supposed to be exported (which they would need to
be if they are to be accessed from the outside).

Тhese classes are only meant to serve as a backend for the swing
interface and a link to the account properties.

They are actually protocol agnostic to some extent so I suppose, if this
is really necessary, we could move part of them to the protocol service.

But yes, before we take a decision it would help to have your use case
explained a bit as Yana asked.

As I wrote in the patch those objects encapsulate operations on
account properties.
Such objects have getters and setters for every account property like
display name or server address.
Now in the UI I operate on values using those getters and I don't have
to know under what property key they should be. There are some special
conditions when they are read/written to AccountID properties and I
didn't wanted to duplicate it on Android.

Also in Android I must be able to persist current UI state between
Activties create/destroy and I use those objects for that. For this
purpose I've made them serializable.

Regards,
Pawel

···

On Wed, May 22, 2013 at 11:47 AM, Emil Ivov <emcho@jitsi.org> wrote:

On 22.05.13, 12:13, Ingo Bauersachs wrote:

Currently SecurityAccountRegistration and EncodingsRegistrationUtil
are in the util package(.util.wizard). Will this place will also be ok
for SIP and Jabber account registration objects ?

No, the util-package needs to stay protocol agnostic.

From logical point
of view maybe it fits more to some SIP and Jabber specific packages.

Definitely.

Regards,
Pawel

Regards,
Ingo

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

--
https://jitsi.org

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


#4

I need to change a littile bit more to reuse the registration classes,
as they are currently located in wizards plugin bundles. I thought
that SIPAccountRegistration and JabberAccountRegistration could be
available from some util or protocol packages.

AFAIK they are UI-independent, so you can move them to the protocol
bundle(s).

No, I'd rather you didn't do that. Protocol implementations are just
that and they are not supposed to be exported (which they would need to
be if they are to be accessed from the outside).

Well, I do get your point. But consider this: The SIP protocol and the SIP wizard are two plugins (yes, I call the SIP protocol a plugin because a service implementation is really just that) that are tightly coupled. The Wizard/UI plugin needs to know about the properties of the protocol. So why not let these two interact with each other?

What we define as services is just what could have independent implementations. A SIP properties holder doesn't fulfill that definition (at least as long as we don't have two SIP protocol implementations).

So apart from having "impl" in its name, what hinders us to export certain packages from a protocol-plugin, which provides services to (a) /dependent/ plugin(s)?

Тhese classes are only meant to serve as a backend for the swing
interface and a link to the account properties.

True, but the advantage of having a registration object is that it is refactoring safe. We could just use the property names again in Android, but each change in the protocol-plugin would cause two following changes in strings that need to be done as well (and easily forgotten as the compiler doesn't complain).

We already discussed that long ago: Those registrations objects could be merged with the (SIP|Jabber)AccountID class.

They are actually protocol agnostic to some extent so I suppose, if this
is really necessary, we could move part of them to the protocol service.

The parts that are really agnostic (and not just common to SIP/Jabber): definitely.

But yes, before we take a decision it would help to have your use case
explained a bit as Yana asked.

Emil

Ingo

···

On 22.05.13, 12:13, Ingo Bauersachs wrote:


#5

I need to change a littile bit more to reuse the registration
classes, as they are currently located in wizards plugin
bundles. I thought that SIPAccountRegistration and
JabberAccountRegistration could be available from some util or
protocol packages.

AFAIK they are UI-independent, so you can move them to the
protocol bundle(s).

No, I'd rather you didn't do that. Protocol implementations are
just that and they are not supposed to be exported (which they
would need to be if they are to be accessed from the outside).

Well, I do get your point. But consider this: The SIP protocol and
the SIP wizard are two plugins (yes, I call the SIP protocol a plugin
because a service implementation is really just that) that are
tightly coupled. The Wizard/UI plugin needs to know about the
properties of the protocol. So why not let these two interact with
each other?

I see what you mean. Still, note that the plugin is coupled with the
protocol itself, not so much with the implementation. We already have
protocol specific stuff in service.prototol so maybe this would be the
best place to store such things.

What we define as services is just what could have independent
implementations. A SIP properties holder doesn't fulfill that
definition

Agreed. Which is why it could live in service.protocol.sip.

(at least as long as we don't have two SIP protocol
implementations).

So apart from having "impl" in its name, what hinders us to export
certain packages from a protocol-plugin, which provides services to
(a) /dependent/ plugin(s)?

Тhese classes are only meant to serve as a backend for the swing
interface and a link to the account properties.

True, but the advantage of having a registration object is that it is
refactoring safe. We could just use the property names again in
Android, but each change in the protocol-plugin would cause two
following changes in strings that need to be done as well (and easily
forgotten as the compiler doesn't complain).

We already discussed that long ago: Those registrations objects could
be merged with the (SIP|Jabber)AccountID class.

Yes this is a good idea. I am OK with modifying the AccountID class to
have accessor methods for any property that concerns more than one
protocol. Maybe some of the stuff from util.wizard can also move there.

Then we can have service.protocol.jabber.JabberAccountID and
service.protocol.sip.SipAccountID with all the stuff that is really
specific to protocols.

Note that this approach would mean that the wizard will create one
AccountID, that would then get passed as properties to the protocol
factory, which would then create a new AccountID instance ... but I
don't have a problem with this.

Does this make sense?

Emil

···

On 22.05.13, 13:32, Ingo Bauersachs wrote:

On 22.05.13, 12:13, Ingo Bauersachs wrote:

--
https://jitsi.org


#6

Yes I'll try to make it this way. At some point I had the same
thoughts, but didn't wanted to make such revolutions in the code.

Regards,
Pawel

···

On Wed, May 22, 2013 at 12:53 PM, Emil Ivov <emcho@jitsi.org> wrote:

On 22.05.13, 13:32, Ingo Bauersachs wrote:

On 22.05.13, 12:13, Ingo Bauersachs wrote:

I need to change a littile bit more to reuse the registration
classes, as they are currently located in wizards plugin
bundles. I thought that SIPAccountRegistration and
JabberAccountRegistration could be available from some util or
protocol packages.

AFAIK they are UI-independent, so you can move them to the
protocol bundle(s).

No, I'd rather you didn't do that. Protocol implementations are
just that and they are not supposed to be exported (which they
would need to be if they are to be accessed from the outside).

Well, I do get your point. But consider this: The SIP protocol and
the SIP wizard are two plugins (yes, I call the SIP protocol a plugin
because a service implementation is really just that) that are
tightly coupled. The Wizard/UI plugin needs to know about the
properties of the protocol. So why not let these two interact with
each other?

I see what you mean. Still, note that the plugin is coupled with the
protocol itself, not so much with the implementation. We already have
protocol specific stuff in service.prototol so maybe this would be the
best place to store such things.

What we define as services is just what could have independent
implementations. A SIP properties holder doesn't fulfill that
definition

Agreed. Which is why it could live in service.protocol.sip.

(at least as long as we don't have two SIP protocol
implementations).

So apart from having "impl" in its name, what hinders us to export
certain packages from a protocol-plugin, which provides services to
(a) /dependent/ plugin(s)?

Тhese classes are only meant to serve as a backend for the swing
interface and a link to the account properties.

True, but the advantage of having a registration object is that it is
refactoring safe. We could just use the property names again in
Android, but each change in the protocol-plugin would cause two
following changes in strings that need to be done as well (and easily
forgotten as the compiler doesn't complain).

We already discussed that long ago: Those registrations objects could
be merged with the (SIP|Jabber)AccountID class.

Yes this is a good idea. I am OK with modifying the AccountID class to
have accessor methods for any property that concerns more than one
protocol. Maybe some of the stuff from util.wizard can also move there.

Then we can have service.protocol.jabber.JabberAccountID and
service.protocol.sip.SipAccountID with all the stuff that is really
specific to protocols.

Note that this approach would mean that the wizard will create one
AccountID, that would then get passed as properties to the protocol
factory, which would then create a new AccountID instance ... but I
don't have a problem with this.

Does this make sense?


#7

A small comment here: the fact is that this concrete sip wizard
implementaion is compatible with our conrete sip protocol
implementation.

Regards,
Pawel

···

On Wed, May 22, 2013 at 12:53 PM, Emil Ivov <emcho@jitsi.org> wrote:

On 22.05.13, 13:32, Ingo Bauersachs wrote:

On 22.05.13, 12:13, Ingo Bauersachs wrote:

I need to change a littile bit more to reuse the registration
classes, as they are currently located in wizards plugin
bundles. I thought that SIPAccountRegistration and
JabberAccountRegistration could be available from some util or
protocol packages.

AFAIK they are UI-independent, so you can move them to the
protocol bundle(s).

No, I'd rather you didn't do that. Protocol implementations are
just that and they are not supposed to be exported (which they
would need to be if they are to be accessed from the outside).

Well, I do get your point. But consider this: The SIP protocol and
the SIP wizard are two plugins (yes, I call the SIP protocol a plugin
because a service implementation is really just that) that are
tightly coupled. The Wizard/UI plugin needs to know about the
properties of the protocol. So why not let these two interact with
each other?

I see what you mean. Still, note that the plugin is coupled with the
protocol itself, not so much with the implementation. We already have
protocol specific stuff in service.prototol so maybe this would be the
best place to store such things.


#8

I need to change a littile bit more to reuse the registration
classes, as they are currently located in wizards plugin
bundles. I thought that SIPAccountRegistration and
JabberAccountRegistration could be available from some util or
protocol packages.

AFAIK they are UI-independent, so you can move them to the
protocol bundle(s).

No, I'd rather you didn't do that. Protocol implementations are
just that and they are not supposed to be exported (which they
would need to be if they are to be accessed from the outside).

Well, I do get your point. But consider this: The SIP protocol and
the SIP wizard are two plugins (yes, I call the SIP protocol a plugin
because a service implementation is really just that) that are
tightly coupled. The Wizard/UI plugin needs to know about the
properties of the protocol. So why not let these two interact with
each other?

I see what you mean. Still, note that the plugin is coupled with the
protocol itself, not so much with the implementation. We already have
protocol specific stuff in service.prototol so maybe this would be the
best place to store such things.

I disagree. The plugin configures a very specific implementation of a (the) protocol. One SIP protocol plugin could simply use SIP_REGISTRAR as the property name for the registrar AND port, another would use BETTER_SIP_REGISTRAR_IP and BETTER_SIP_REGISTRAR_PORT, yet another implementation doesn't even have the possibility to configure the registrar (exchange registrar with XCAP/XiVO support, you name it). The config plugin needs to know about that is hence coupled to a very specific implementation, not just to any SIP protocol plugin. If there were shared stuff between multiple SIP protocol plugins - that should go into service.protocol.sip.

Granted, we don't have multiple protocol implementations, but the architectural view still applies.

What we define as services is just what could have independent
implementations. A SIP properties holder doesn't fulfill that
definition

Agreed. Which is why it could live in service.protocol.sip.

(at least as long as we don't have two SIP protocol
implementations).

So apart from having "impl" in its name, what hinders us to export
certain packages from a protocol-plugin, which provides services to
(a) /dependent/ plugin(s)?

Тhese classes are only meant to serve as a backend for the swing
interface and a link to the account properties.

True, but the advantage of having a registration object is that it is
refactoring safe. We could just use the property names again in
Android, but each change in the protocol-plugin would cause two
following changes in strings that need to be done as well (and easily
forgotten as the compiler doesn't complain).

We already discussed that long ago: Those registrations objects could
be merged with the (SIP|Jabber)AccountID class.

Yes this is a good idea. I am OK with modifying the AccountID class to
have accessor methods for any property that concerns more than one
protocol. Maybe some of the stuff from util.wizard can also move there.

Then we can have service.protocol.jabber.JabberAccountID and
service.protocol.sip.SipAccountID with all the stuff that is really
specific to protocols.

I don't like that - same reason as above.

Note that this approach would mean that the wizard will create one
AccountID, that would then get passed as properties to the protocol
factory, which would then create a new AccountID instance ... but I
don't have a problem with this.

Yes. However it is up to the factory on how to use the received AccountID. But a clone is probably wise.

Does this make sense?

Emil

Ingo

···

On 22.05.13, 13:32, Ingo Bauersachs wrote:

On 22.05.13, 12:13, Ingo Bauersachs wrote:


#9

I need to change a littile bit more to reuse the registration
classes, as they are currently located in wizards plugin
bundles. I thought that SIPAccountRegistration and
JabberAccountRegistration could be available from some util or
protocol packages.

AFAIK they are UI-independent, so you can move them to the
protocol bundle(s).

No, I'd rather you didn't do that. Protocol implementations are
just that and they are not supposed to be exported (which they
would need to be if they are to be accessed from the outside).

Well, I do get your point. But consider this: The SIP protocol and
the SIP wizard are two plugins (yes, I call the SIP protocol a plugin
because a service implementation is really just that) that are
tightly coupled. The Wizard/UI plugin needs to know about the
properties of the protocol. So why not let these two interact with
each other?

I see what you mean. Still, note that the plugin is coupled with the
protocol itself, not so much with the implementation. We already have
protocol specific stuff in service.prototol so maybe this would be the
best place to store such things.

A small comment here: the fact is that this concrete sip wizard
implementaion is compatible with our conrete sip protocol implementation.

Exactly!

Regards,
Pawel

Ingo

···

On 22.05.13, 13:32, Ingo Bauersachs wrote:

On 22.05.13, 12:13, Ingo Bauersachs wrote:


#10

This might be the situation yes. In general however we should be
striving to make sure that whatever behaviour we expect from the
protocol is visible through the service interfaces. The opposite should
apply to impl. In other words: "What happens in Impl, stays in Impl" :wink:

Emil

···

On 22.05.13, 14:10, Paweł Domas wrote:

A small comment here: the fact is that this concrete sip wizard
implementaion is compatible with our conrete sip protocol
implementation.


#11

Disclaimer: I might be missing or misunderstanding something.

more inline

I need to change a littile bit more to reuse the
registration classes, as they are currently located in
wizards plugin bundles. I thought that
SIPAccountRegistration and JabberAccountRegistration could
be available from some util or protocol packages.

AFAIK they are UI-independent, so you can move them to the
protocol bundle(s).

No, I'd rather you didn't do that. Protocol implementations
are just that and they are not supposed to be exported (which
they would need to be if they are to be accessed from the
outside).

Well, I do get your point. But consider this: The SIP protocol
and the SIP wizard are two plugins (yes, I call the SIP protocol
a plugin because a service implementation is really just that)
that are tightly coupled. The Wizard/UI plugin needs to know
about the properties of the protocol. So why not let these two
interact with each other?

I see what you mean. Still, note that the plugin is coupled with
the protocol itself, not so much with the implementation. We
already have protocol specific stuff in service.prototol so maybe
this would be the best place to store such things.

I disagree. The plugin configures a very specific implementation of a
(the) protocol. One SIP protocol plugin could simply use
SIP_REGISTRAR as the property name for the registrar AND port,
another would use BETTER_SIP_REGISTRAR_IP and
BETTER_SIP_REGISTRAR_PORT,

I am not sure why we would want to allow and support such differences.
To me it sounds completely reasonable to mandate that any SIP
implementation in Jitsi is initialized the same way.

I don't see the use case for having two different implementations that
have completely and totally different init properties.

yet another implementation doesn't even
have the possibility to configure the registrar (exchange registrar
with XCAP/XiVO support, you name it).

It sounds to me like this would mostly be a matter for the wizard. This
is how we currently handle custom protocols such as GTalk or ippi and so
far it does the job.

Every different wizard overrides some default properties or hides others.

The config plugin needs to know
about that is hence coupled to a very specific implementation, not
just to any SIP protocol plugin.

The config plugin does know this by looking at the service signature.

If there were shared stuff between
multiple SIP protocol plugins - that should go into
service.protocol.sip.

I agree with this part and again, I think it is reasonable to mandate
that our current properties (which are already defined in
ProtocolProvierFactory) be respected by any future implementations.

Granted, we don't have multiple protocol implementations, but the
architectural view still applies.

It does and I am not sure how it contradicts what I am saying.

Note that the service interfaces are there not only as a way for others
to find out how to interact with the implementation. They are also there
to indicate how the implementation should behave.

I think that it is quite natural that, with time, we would be moving
some parts from within impl and into service, as we discover that these
parts are inherent to the way Jitsi works.

We should be adapting to the experiences we have not to the possible
things that could happen. In this case experience shows that protocols
are a fairly immutable part of Jitsi so in this case the service
interfaces are there to protect against changes in the implementation,
and no longer to really accommodate for competing implementations.

I think that such isolation is still important.

Emil

···

On 22.05.13, 14:14, Ingo Bauersachs wrote:

On 22.05.13, 13:32, Ingo Bauersachs wrote:

On 22.05.13, 12:13, Ingo Bauersachs wrote:

What we define as services is just what could have independent
implementations. A SIP properties holder doesn't fulfill that
definition

Agreed. Which is why it could live in service.protocol.sip.

(at least as long as we don't have two SIP protocol
implementations).

So apart from having "impl" in its name, what hinders us to
export certain packages from a protocol-plugin, which provides
services to (a) /dependent/ plugin(s)?

Тhese classes are only meant to serve as a backend for the
swing interface and a link to the account properties.

True, but the advantage of having a registration object is that
it is refactoring safe. We could just use the property names
again in Android, but each change in the protocol-plugin would
cause two following changes in strings that need to be done as
well (and easily forgotten as the compiler doesn't complain).

We already discussed that long ago: Those registrations objects
could be merged with the (SIP|Jabber)AccountID class.

Yes this is a good idea. I am OK with modifying the AccountID class
to have accessor methods for any property that concerns more than
one protocol. Maybe some of the stuff from util.wizard can also
move there.

Then we can have service.protocol.jabber.JabberAccountID and
service.protocol.sip.SipAccountID with all the stuff that is
really specific to protocols.

I don't like that - same reason as above.

Note that this approach would mean that the wizard will create one
AccountID, that would then get passed as properties to the
protocol factory, which would then create a new AccountID instance
... but I don't have a problem with this.

Yes. However it is up to the factory on how to use the received
AccountID. But a clone is probably wise.

Does this make sense?

Emil

Ingo

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

--
https://jitsi.org


#12

After looking some more at it maybe they could stay "registration"
objects not the AccountID. The reason for this is that they are used
to encapsulate the edit process on given account and they have to be
stored thorught ProtocolProviderFactory after the process. Someone may
think that it's that simple to just set the property of SipAccountID
while it's not. Also it will require less work, because all I would
have to do now would be just to extract common parts into
AccountRegistration base class. This class could be in
service.protocol ?

Regards,
Pawel

···

On Wed, May 22, 2013 at 1:35 PM, Emil Ivov <emcho@jitsi.org> wrote:

Disclaimer: I might be missing or misunderstanding something.

more inline

On 22.05.13, 14:14, Ingo Bauersachs wrote:

On 22.05.13, 13:32, Ingo Bauersachs wrote:

On 22.05.13, 12:13, Ingo Bauersachs wrote:

I need to change a littile bit more to reuse the
registration classes, as they are currently located in
wizards plugin bundles. I thought that
SIPAccountRegistration and JabberAccountRegistration could
be available from some util or protocol packages.

AFAIK they are UI-independent, so you can move them to the
protocol bundle(s).

No, I'd rather you didn't do that. Protocol implementations
are just that and they are not supposed to be exported (which
they would need to be if they are to be accessed from the
outside).

Well, I do get your point. But consider this: The SIP protocol
and the SIP wizard are two plugins (yes, I call the SIP protocol
a plugin because a service implementation is really just that)
that are tightly coupled. The Wizard/UI plugin needs to know
about the properties of the protocol. So why not let these two
interact with each other?

I see what you mean. Still, note that the plugin is coupled with
the protocol itself, not so much with the implementation. We
already have protocol specific stuff in service.prototol so maybe
this would be the best place to store such things.

I disagree. The plugin configures a very specific implementation of a
(the) protocol. One SIP protocol plugin could simply use
SIP_REGISTRAR as the property name for the registrar AND port,
another would use BETTER_SIP_REGISTRAR_IP and
BETTER_SIP_REGISTRAR_PORT,

I am not sure why we would want to allow and support such differences.
To me it sounds completely reasonable to mandate that any SIP
implementation in Jitsi is initialized the same way.

I don't see the use case for having two different implementations that
have completely and totally different init properties.

yet another implementation doesn't even
have the possibility to configure the registrar (exchange registrar
with XCAP/XiVO support, you name it).

It sounds to me like this would mostly be a matter for the wizard. This
is how we currently handle custom protocols such as GTalk or ippi and so
far it does the job.

Every different wizard overrides some default properties or hides others.

The config plugin needs to know
about that is hence coupled to a very specific implementation, not
just to any SIP protocol plugin.

The config plugin does know this by looking at the service signature.

If there were shared stuff between
multiple SIP protocol plugins - that should go into
service.protocol.sip.

I agree with this part and again, I think it is reasonable to mandate
that our current properties (which are already defined in
ProtocolProvierFactory) be respected by any future implementations.


#13

Disclaimer: I might be missing or misunderstanding something.

more inline

I need to change a littile bit more to reuse the
registration classes, as they are currently located in
wizards plugin bundles. I thought that
SIPAccountRegistration and JabberAccountRegistration could
be available from some util or protocol packages.

AFAIK they are UI-independent, so you can move them to the
protocol bundle(s).

No, I'd rather you didn't do that. Protocol implementations
are just that and they are not supposed to be exported (which
they would need to be if they are to be accessed from the
outside).

Well, I do get your point. But consider this: The SIP protocol
and the SIP wizard are two plugins (yes, I call the SIP protocol
a plugin because a service implementation is really just that)
that are tightly coupled. The Wizard/UI plugin needs to know
about the properties of the protocol. So why not let these two
interact with each other?

I see what you mean. Still, note that the plugin is coupled with
the protocol itself, not so much with the implementation. We
already have protocol specific stuff in service.prototol so maybe
this would be the best place to store such things.

I disagree. The plugin configures a very specific implementation of a
(the) protocol. One SIP protocol plugin could simply use
SIP_REGISTRAR as the property name for the registrar AND port,
another would use BETTER_SIP_REGISTRAR_IP and
BETTER_SIP_REGISTRAR_PORT,

I am not sure why we would want to allow and support such differences.
To me it sounds completely reasonable to mandate that any SIP
implementation in Jitsi is initialized the same way.

I don't see the use case for having two different implementations that
have completely and totally different init properties.

yet another implementation doesn't even
have the possibility to configure the registrar (exchange registrar
with XCAP/XiVO support, you name it).

It sounds to me like this would mostly be a matter for the wizard. This
is how we currently handle custom protocols such as GTalk or ippi and so
far it does the job.

Every different wizard overrides some default properties or hides others.

The config plugin needs to know
about that is hence coupled to a very specific implementation, not
just to any SIP protocol plugin.

The config plugin does know this by looking at the service signature.

If there were shared stuff between
multiple SIP protocol plugins - that should go into
service.protocol.sip.

I agree with this part and again, I think it is reasonable to mandate
that our current properties (which are already defined in
ProtocolProvierFactory) be respected by any future implementations.

After looking some more at it maybe they could stay "registration"
objects not the AccountID. The reason for this is that they are used
to encapsulate the edit process on given account and they have to be
stored thorught ProtocolProviderFactory after the process.

Right and this will continue happening! You will use one version of the
account ID in the wizard and you would then pass it to the factory.

Someone may
think that it's that simple to just set the property of SipAccountID
while it's not.

Why is that?

Also it will require less work, because all I would
have to do now would be just to extract common parts into
AccountRegistration base class. This class could be in
service.protocol ?

Moving things to AccountID would also involve a lot of code reuse and I
think that the clarity of the new structure is worth the overhead (which
is the position we've been taking when redoing a lot of the things to
better work for Android).

Emil

···

On 22.05.13, 14:52, Paweł Domas wrote:

On Wed, May 22, 2013 at 1:35 PM, Emil Ivov <emcho@jitsi.org> wrote:

On 22.05.13, 14:14, Ingo Bauersachs wrote:

On 22.05.13, 13:32, Ingo Bauersachs wrote:

On 22.05.13, 12:13, Ingo Bauersachs wrote:

Regards,
Pawel

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

--
https://jitsi.org


#14

Hi Pawel,

After looking some more at it maybe they could stay "registration"
objects not the AccountID. The reason for this is that they are used
to encapsulate the edit process on given account and they have to be
stored thorught ProtocolProviderFactory after the process.

If I understand it right this part stays the same though.

Someone may
think that it's that simple to just set the property of SipAccountID
while it's not.

I don't really see what do you mean? When I look at the installAccount() method of the wizard, it's mostly about storing the registration properties in the account properties, nothing more.

Cheers,
Yana

···

On May 22, 2013, at 2:52 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Also it will require less work, because all I would
have to do now would be just to extract common parts into
AccountRegistration base class. This class could be in
service.protocol ?

Regards,
Pawel

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


#15

I meant that when you have AccountID and you change some property to
take effect it have to go through the ProtocolProviderFactory.
Currently it have mostly getters.

Anyway I'll try to refactor it to AccountID. Just wanted to signal
that it will take more time and tried to suggest a shortcut :slight_smile:

Regards,
Pawel

···

On Wed, May 22, 2013 at 2:03 PM, Yana Stamcheva <yana@jitsi.org> wrote:

Hi Pawel,

On May 22, 2013, at 2:52 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

After looking some more at it maybe they could stay "registration"
objects not the AccountID. The reason for this is that they are used
to encapsulate the edit process on given account and they have to be
stored thorught ProtocolProviderFactory after the process.

If I understand it right this part stays the same though.

Someone may
think that it's that simple to just set the property of SipAccountID
while it's not.

I don't really see what do you mean? When I look at the installAccount() method of the wizard, it's mostly about storing the registration properties in the account properties, nothing more.


#16

Hi Pawel,

After looking some more at it maybe they could stay "registration"
objects not the AccountID. The reason for this is that they are used
to encapsulate the edit process on given account and they have to be
stored thorught ProtocolProviderFactory after the process.

If I understand it right this part stays the same though.

Someone may
think that it's that simple to just set the property of SipAccountID
while it's not.

I don't really see what do you mean? When I look at the installAccount() method of the wizard, it's mostly about storing the registration properties in the account properties, nothing more.

I meant that when you have AccountID and you change some property to
take effect it have to go through the ProtocolProviderFactory.

Yes, this will still be the case. The use of AccountID in the wizard
will be independent from the one in the protocol.

Emil

···

On 22.05.13, 15:11, Paweł Domas wrote:

On Wed, May 22, 2013 at 2:03 PM, Yana Stamcheva <yana@jitsi.org> wrote:

On May 22, 2013, at 2:52 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Currently it have mostly getters.

Anyway I'll try to refactor it to AccountID. Just wanted to signal
that it will take more time and tried to suggest a shortcut :slight_smile:

Regards,
Pawel

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

--
https://jitsi.org


#17

Hi,

During refactoring process I've encountered optional contact lists
properties that are duplicated.
We can have local, XCAP or XiVO contact lists used for SIP as far as I
understand the code.
There are separate properties for XCAP server, user, password and for
XiVO server, user and password.

For edit purposes in the registration object all are hidden behind
ClistOptionServerUri, ClistOptionUser and ClistOptionPassword fields.
When registration form is stored depends if local, XCAP or XiVO list
type is enabled they are stored under different property keys(XCAP,
XiVO or none for local).

What I want to do is to change to use only one property key set. Then
in the code for XCAP just use getClistOptionUser and
getClistOptionPassword instead of direct XCAP properties. For backward
compatiblity I would write something like this in the getter:

   /**
     * Gets the contact list user.

···

*
     * @return the contact list user.
     */
    public String getClistOptionUser()
    {
        String clistUser = getAccountPropertyString(OPT_CLIST_USER);
        if(clistUser == null)
        {
            // For backward compatibility
            String oldKey = isXCapEnable() ? "XCAP_USER" :
"XiVO_USER";
            clistUser = getAccountPropertyString(oldKey);
            if(clistUser != null)
            {
                // remove old key
                accountProperties.remove(oldKey);
                // store under new property key
                setClistOptionUser(clistUser);
            }
        }
        return clistUser;
    }

This should not cause any problems as long as we use only one contact
list and never XCAP and XiVO(or local) at once. Are we ?

Regards,
Pawel


#18

Hi,

I have one more question. Will it be preferred to keep account
properties inside the hashmap or as class member fields ?

In first case getters/setters will read/write properties directly from
the hashmap and copy the whole map during account loading/storage.

In second case account ID will put fields into hashmap before is
stored and will extract them during account loading.

Regards,
Pawel

···

On Thu, May 23, 2013 at 1:56 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Hi,

During refactoring process I've encountered optional contact lists
properties that are duplicated.
We can have local, XCAP or XiVO contact lists used for SIP as far as I
understand the code.
There are separate properties for XCAP server, user, password and for
XiVO server, user and password.

For edit purposes in the registration object all are hidden behind
ClistOptionServerUri, ClistOptionUser and ClistOptionPassword fields.
When registration form is stored depends if local, XCAP or XiVO list
type is enabled they are stored under different property keys(XCAP,
XiVO or none for local).

What I want to do is to change to use only one property key set. Then
in the code for XCAP just use getClistOptionUser and
getClistOptionPassword instead of direct XCAP properties. For backward
compatiblity I would write something like this in the getter:

   /**
     * Gets the contact list user.
     *
     * @return the contact list user.
     */
    public String getClistOptionUser()
    {
        String clistUser = getAccountPropertyString(OPT_CLIST_USER);
        if(clistUser == null)
        {
            // For backward compatibility
            String oldKey = isXCapEnable() ? "XCAP_USER" :
"XiVO_USER";
            clistUser = getAccountPropertyString(oldKey);
            if(clistUser != null)
            {
                // remove old key
                accountProperties.remove(oldKey);
                // store under new property key
                setClistOptionUser(clistUser);
            }
        }
        return clistUser;
    }

This should not cause any problems as long as we use only one contact
list and never XCAP and XiVO(or local) at once. Are we ?

Regards,
Pawel


#19

I have one more question. Will it be preferred to keep account
properties inside the hashmap or as class member fields ?

I'd say stay with the hashmap. If there's going to be a field for every property, the AccountID-objects becomes about twice the (in-memory) size (assuming the hashmap stays referenced anyway). And memory is used even for properties that have no value.

In first case getters/setters will read/write properties directly from
the hashmap and copy the whole map during account loading/storage.

In second case account ID will put fields into hashmap before is
stored and will extract them during account loading.

Regards,
Pawel

While you're doing refactorings: Could we somehow use the jitsi-defaults.properties for default-values in the accounts as well? So instead of providing defaults for e.g. getAccountPropertyBoolean in the code, get them from jitsi-defaults.

Ingo


#20

Hi Ingo,

I have one more question. Will it be preferred to keep account
properties inside the hashmap or as class member fields ?

I'd say stay with the hashmap. If there's going to be a field for every property, the AccountID-objects becomes about twice the (in-memory) size (assuming the hashmap stays referenced anyway). And memory is used even for properties that have no value.

I also vote for the hashmap. Fields would introduce ambiguousity, as
account properties hashmap is available at the same time. The reason I
asked is that there are some final properties in the AccounID:
protocolName, userID, accountUID and few others. All of them have
property keys in ProtocolProviderFactory I'm not sure if this will be
ok to remove them.

In first case getters/setters will read/write properties directly from
the hashmap and copy the whole map during account loading/storage.

In second case account ID will put fields into hashmap before is
stored and will extract them during account loading.

Regards,
Pawel

While you're doing refactorings: Could we somehow use the jitsi-defaults.properties for default-values in the accounts as well? So instead of providing defaults for e.g. getAccountPropertyBoolean in the code, get them from jitsi-defaults.

Ingo

Sure I'll take a look how these work and try to use of them.

Regards,
Pawel

···

On Fri, May 24, 2013 at 2:43 PM, Ingo Bauersachs <ingo@jitsi.org> wrote: