OK, so as I see it there are various ways to fix this:
a) Not a bug - If they care about data-sources they should keep track of them (GetDataSources at start and DataSourceRegistered after that). However, what should be fixed is the DataSourceDisconnected signal, it is currently sending the whole data-source information while just the unique id should be enough.
b) Change DataSourceEnabled to send the whole data-source, so it's consistent with DataSourceRegistered and DataSourceDisconnected.
c) Leave DataSourceEnabled as it is, fix DataSourceDisconnected to only return the unique id (see A) and add a GetDataSourceForId method.
Personally I don't see what a) or b) would bring us. If you're a data-source yourself you'll probably just want to check whether the ID is yours to know what happened to you. If you're a data-source management GUI, which wants to update the information when something is enabled/disabled, you'll be keep track of all data-sources anyway, through a GetDataSources call at startup and successive updates thanks to DataSourceRegistered signals. This means that when you get a DataSourceEnabled signal you already have the information about the event, and getting a full copy of it won't make your work any easier than just having the unique ID.
OK, so as I see it there are various ways to fix this:
a) Not a bug - If they care about data-sources they should keep track of them (GetDataSources at start and DataSourceRegis tered after that). However, what should be fixed is the DataSourceDisco nnected signal, it is currently sending the whole data-source information while just the unique id should be enough.
b) Change DataSourceEnabled to send the whole data-source, so it's consistent with DataSourceRegis tered and DataSourceDisco nnected.
c) Leave DataSourceEnabled as it is, fix DataSourceDisco nnected to only return the unique id (see A) and add a GetDataSourceForId method.
Personally I don't see what a) or b) would bring us. If you're a data-source yourself you'll probably just want to check whether the ID is yours to know what happened to you. If you're a data-source management GUI, which wants to update the information when something is enabled/disabled, you'll be keep track of all data-sources anyway, through a GetDataSources call at startup and successive updates thanks to DataSourceRegis tered signals. This means that when you get a DataSourceEnabled signal you already have the information about the event, and getting a full copy of it won't make your work any easier than just having the unique ID.