Disclaimer: I might be missing or misunderstanding something.
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
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
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
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
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.
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
Agreed. Which is why it could live in service.protocol.sip.
(at least as long as we don't have two SIP protocol
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
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?
_______________________________________________ dev mailing list
email@example.com Unsubscribe instructions and other list options: