DataSourceRegistry should have GetDataSourceForId method

[Jeremy Whiting]

DataSourceRegistry should have a way to get a DataSource from it's id especially because the DataSourceEnabled signal only sends an id rather than a DataSource in the signal.

[Siegfried Gevatter (rainct)]

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.

[Jeremy Whiting (jeremy-whiting)]

Ah, I see, yeah I agree with the analysis above. I suggest solution c at this point.

[Siegfried Gevatter (rainct)]

(Uhm, I had send out an e-mail about this earlier but it looks like Launchpad lost it:)

There's a typo in my first comment, what I meant is "b) or c)", not "a) or b)". That is, the solution I'd prefer is a). After that I'd choose b), since a GetDataSourceForId method by itself (without the signals) isn't really useful -- you need to know the IDs to ask for them.

Thoughts?

[Jeremy Whiting (jeremy-whiting)]

Oh, I see what you meant. Yeah, b would be helpful I believe from our standpoint. Then the signals would be consistent.

[Siegfried Gevatter (rainct)]

Fine with me. Unless someone else comments, I'll implement solution b) once the branch I've currently waiting gets merged.

[Mikkel Kamstrup Erlandsen (kamstrup)]

Siegfried; what you propose is breaking the DBus API, which will force
me to break ABI and API of libzeitgeist => mikkel becomes unpopular.

That said, I do see the merit in what you are proposing. It just has
some consequences...

[Seif Lotfy (seif)]

Solution b is not an option since as Mikkel stated it will break the API and ABI
I think we are stuck with adding the GetDataSourceForid method. It wont harm any1 and will satisfy the case we have