Actually, there's something about this where point of views differ fundamentally...
libjitsi is a library that needs some configuration. However, this config is dependent on the application it runs in (e.g. Jitsi, the Videobridge, etc.).
So, my point of view is that every application should provide its own implementation of the ConfigurationService interface and libjitsi should not even provide a default implementation - it cannot deal with application specific details (like /etc/jitsi or /etc/jitsi-videobridge/...).
So far, the other developers disagreed about that.
And now you come with code duplication
I wonder how we could avoid that. The two implemenations differ fundamentally and e.g. the videobridge as a server-application for sure doesn't need all that override, transaction and user writable capabilities. All it needs is a default and a config that overrides this from /etc/something.
As for JdbcConfigService: that is intended to replace the libjitsi implementation for Jitsi because reading and writing .properties files is too slow and unreliable for big configs (like Emils 10mb file or my 1mb). It's just not the default (yet). Although, I think we could do that by now, at least for the nightlies. I used it over months without any problems - and AFAIK Emil as well.
-- sent from my mobile
Le 24.07.2014 à 18:56, "Daniel Pocock" <firstname.lastname@example.org> a écrit :
On 24/07/14 13:07, Lyubomir Marinov wrote:
На 24.07.2014 в 13:54, Daniel Pocock написа:
LibJitsi's ConfigurationServiceImpl is the default
ConfigurationService implementation in general and of Jitsi in
JdbcConfigService is not the default ConfigurationService
implementation of Jitsi, it need to be explicitly enabled.
Ok, thanks for clarifying that
I did a string search for "jitsi-defaults.properties" in the Jitsi
repository and JdbcConfigService is the only class that contains the
string, so that is how I started working in there.
the code is duplicated in the libjitsi project:
JdbcConfigService has duplicated ConfigurationServiceImpl.
Is it necessary for a patch to be submitted against both of these source
Ideally, a patch would eliminate the duplicate source code between
ConfigurationServiceImpl and JdbcConfigService and another patch would
fix the issue that is of primary interest to you. Anyway, you would be
submitting the patch so feel free to submit it against whatever you
So far I just submitted a patch against libjitsi ConfigurationServiceImpl
Should JdbcConfigService (and potentially other implementations?) be
written as subclasses of ConfigurationServiceImpl perhaps? This might
take a little refactoring.
dev mailing list
Unsubscribe instructions and other list options: