| [mylyn-integrators] Task repository design enforces one client? |
|
From what I can tell, the TaskRepository class represents
the repository (server) and the interface
(client) to the task repository. This assumption probably makes life simpler
from Mylyn’s point of view, but it lacks flexibility. An example: - The repository server and database resides
at myserver.mydomain.org:1234. - A web-based client is available at http://accessrepository.mydomain.org - A separate windows thick client is available
from winaccessrepository.mydomain.org In my example, the same
repository tasks could be accessed and modified by either the web or windows
client. It doesn’t make sense to define the web-based client as one
task repository and the windows thick client as a separate task repository.
But I think this is what the Mylyn TaskRepository design enforces. From
looking at other connectors (Bugzilla, Trac, and Jira), it appears they’re
quite happy with this restriction. So perhaps this has never been an
issue before? If each client were identified as a separate
TaskRepository instance, my understanding is that each instance would have its
own task list, managed separately, even though they’re really the same
tasks from the same repository server. I’m working on a ClearQuest connector for an
environment that’s similar to the above example. The repository
server and database resides at one URL, but there are multiple interfaces available
to access and modify tasks and bugs from that repository: a web-client on
one server (CQWeb interface) and a windows thick client on another. Thanks, |