[jitsi-dev] [libjitsi] Merge branch 'jitsi.properties' (411f495)


#1

The methods that return available property names (getAllByPrefix and the sort) should also respect the defaults.

Yes and they will. It is simply not ready yet :slight_smile:

> I was wondering whether we should fire VetoMessages for immutable properties instead of silently doing nothing.

You mean adding a new listener to the ConfigurationService that would deliver such veto notifications? I see the point but I think I'd prefer that we added that the first time we needed it somewhere. (e.g. once we have components that would handle such notifications and do something meaningful with them.

Deployment: we need to make sure that we don't simply overwrite customizations to the new deraults file...

Now this would be tricky. If this is to become our new defaults file, we need to be able to update it with new versions that could add/remove or change existing properties. I know that what you have in mind is changes that have been made by the deployer but currently the only way I see around this would be to have the deployer redistribute a new file that merges both as necessary.

路路路

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/libjitsi/commit/411f495219661d0ce9ec3a7be2b52ee6901159d0#commitcomment-3254354


#2

The methods that return available property names (getAllByPrefix and
the sort) should also respect the defaults.

Yes and they will. It is simply not ready yet :slight_smile:

Sorry, you only said the deployments are not yet ready :wink:

I was wondering whether we should fire VetoMessages for immutable
properties instead of silently doing nothing.

You mean adding a new listener to the ConfigurationService that would deliver
such veto notifications? I see the point but I think I'd prefer that we added
that the first time we needed it somewhere. (e.g. once we have components
that would handle such notifications and do something meaningful with them.

No, just notifying already registered listeners.

Deployment: we need to make sure that we don't simply overwrite
customizations to the new deraults file...

Now this would be tricky. If this is to become our new defaults file, we
need to be able to update it with new versions that could add/remove or
change existing properties.

I know :slight_smile:

I know that what you have in mind is changes
that have been made by the deployer but currently the only way I see
around this would be to have the deployer redistribute a new file that
merges both as necessary.

Maybe we could use a third file: On Windows there's %ProgramData%. It contains common user-data that is not writable for users. So we could take the following priority for props:
- programdata
- installation-directory
- user-directory

So any modification needed for all users, like adding the two properties for the provisioning url and method, could be added to the programdata. Nothing else would be needed there and we're upgrade-safe for the install-dir file.

OTOH it is probably not too much asked to update the installdir-file for enterprise deployments on update-rollouts.


#3

The methods that return available property names (getAllByPrefix and
the sort) should also respect the defaults.

Yes and they will. It is simply not ready yet :slight_smile:

Sorry, you only said the deployments are not yet ready :wink:

Soon :slight_smile:

I was wondering whether we should fire VetoMessages for immutable
properties instead of silently doing nothing.

You mean adding a new listener to the ConfigurationService that would deliver
such veto notifications? I see the point but I think I'd prefer that we added
that the first time we needed it somewhere. (e.g. once we have components
that would handle such notifications and do something meaningful with them.

No, just notifying already registered listeners.

So just to be clear. Veto listeners are currently notified for any
property change so that they could prevent it. They do this by throwing
a property veto exception. There is no notification of the actual vetoing.

This whole will not happen for immutable properties because no change
will occur.

Even if we did change this and fired property change events for
immutable properties, this will not be enough for a listener to
understand whether or not the property change actually succeeded.

Forcing an exception on the other hand would be a bad idea, at least in
the current state of things. It is possible for any property to be
declared immutable which means that all property modifications
everywhere in Jitsi have to be prepared to handle such exceptions. This
is not currently the case.

Deployment: we need to make sure that we don't simply overwrite
customizations to the new deraults file...

Now this would be tricky. If this is to become our new defaults file, we
need to be able to update it with new versions that could add/remove or
change existing properties.

I know :slight_smile:

I know that what you have in mind is changes
that have been made by the deployer but currently the only way I see
around this would be to have the deployer redistribute a new file that
merges both as necessary.

Maybe we could use a third file: On Windows there's %ProgramData%. It contains common user-data that is not writable for users. So we could take the following priority for props:
- programdata
- installation-directory

Hmm ... actually if we use a third file it could just as well be in the
installation-directory and just carry a different name. This would be a
two line change so I wouldn't mind.

Does this sound good?

Emil

路路路

On 21.05.13, 12:01, Ingo Bauersachs wrote:

--
https://jitsi.org