RE: [mylyn-integrators] Task repository design enforces one client?

[Brandon White <brandonjacob@xxxxxxx>]

Thank you for your response Steffen. I have some comments.

I think there's a misunderstanding here. I probably didn't state my question
clearly.

I agree with you that the TaskRepository is meant to store configuration
settings and I wasn't suggesting that it be extended to provide logic for
connecting to a repository. The TaskRepository stores properties for _one_
url, _one_ set of authorization tokens, _one_ proxy, etc.

My question is/was: what do these properties represent? Do they refer to the
task repository server or an interface/service on that repository? 

I think you answer this question later on when you say I should settle on
one location (web client url) to uniquely identify the repository. So, those
properties represent the "main" interface/service. Is that a correct
assertion?

Furthermore, you suggest storing other parameters for alternate
interfaces/services in the same task repository instance. Fair enough.
However, it means storing more information than just the url for the
alternate client. The alternate client(s) may have different proxy or
authentication information.

Based on my quick read of the AbstractRepositorySettingsPage class, it looks
like I could use its existing functionality for entering configuration
information for the "main" interface/service. But I would have to either
override the createAdditionalControls method to allow users to enter
additional interfaces/services; or add new pages to the Wizard.

Thanks,
Brandon