Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mylyn-integrators] Task repository design enforces one client?

On Tuesday 22 January 2008, Brandon White wrote:
> >>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.

The purpose of the TaskRepository class is store configuration settings for a 
particular repository such as url, character set, proxy information etc. It 
is not meant to be extended or to provide logic for connecting to a 
repository.

> 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?

The JIRA connector has a similar architecture. Communication is done through a 
SOAP interface as well as through JIRA's web interface. The JiraRpcClient 
class delegates calls to the respective interface: JiraWebIssueService or 
JiraSoapService. For each JIRA TaskRepository a corresponding instance of 
JiraRpcClient exists which is managed in JiraClientManager. 

As a side note: Instead of using TaskRepository directly in JiraRpcClient an 
AbstractWebLocation object is constructed from the TaskRepository object. 
AbstractWebLocation offers additional facilities such as access to system 
proxy settings or password prompting in case of authentication failures.

> 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.

The Mylyn UI uses a single task list to manage all tasks from all 
repositories. This instance of the task list can be accessed through 
TasksUiPlugin.getTaskListManager().getTaskList().

> 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.

You probably want to settle on one location to uniquly identify the repository 
(e.g. the web url) and store other parameters required to establish the 
connection like the path to the windows thick client in the same 
TaskRepository object. 

Steffen

-- 
Steffen Pingel - steffenp@xxxxxx - http://steffenpingel.de


Back to the top