Could someone explain me the reasoning that was behind moving the
configuration service into libjitsi? Complete in terms of including the
implementation and not just an interface the necessary implementation.
We wanted to provide an implementation of ConfigurationService because
it is a non-trivial interface to implement and we wanted the users of
the libjitsi library to have an easy and ready way to take advantage
of the ConfigurationService.
Does anyone have objections against stripping down the ConfigurationService
interface in libjitsi?
Stripped down to what is really needed would mean
- remove the fields which are only used by Jitsi's Unit-Tests
- remove methods not used by libjitsi
- no configuration store choices
Which would mean providing a very basic, properties-based only,
Whoever would need more, can then implement the simpler configuration
service. Granted, this will still not be too trivial, but after all,
libjitsi is a library - configuration must really be up to the application
On the other hand, we could leave it as is and I just copy over the
impl.configuration package back into Jitsi and start modifying it there. But
I don't feel very comfortable having that code duplicated...
2013/2/14 Ingo Bauersachs <firstname.lastname@example.org>: