Bug 196511

Description Alex Blewitt 2007-07-13 17:47:26 EDT

There's a lot of reliance on URLs in the current API set that needs implementing. This seems more to do with how it evolved rather than any particular benefit. It would be much nicer if there was a way of representing relationships between Tasks and Repositories; and a lot easier to implement new connectors.

For example, not all bug tracking systems have a web-based interface, or use 'urls' at all. However, one might have an API to query and get a set of results back, or indeed to navigate parent/child relationships (e.g. records in a database). Having methods like 'getUrlFromTaskUrl' don't really have any concept here, whereas (e.g.) TaskRepository.getTask(id): Task would be trivial to implement.

Navigation the other way (e.g. getUrl(repository,taskid) is just as difficult when dealing with the abstract identifiers. On theother and, representing such parent/child links (and their navigation) is easy. If you really needed a unique identifier for each item, you could have Task.getId() or Repository.getId(), but it needn't be the primary form of navigation.

It's also not clear what the purpose of URLs are if there's no web-based interface to it, and thus won't be openable by the system.

Lastly, some URLs (e.g. bugzilla, sourceforge) don't have the mapping stored in the URL anyway. So if you wanted to get the task container URL from the task, it's going to involve a server trip or cache to the object relationship to derive the result, when chances are the caller will then go back and hit getObjectFor(url)

I'm mostly throwing this in for feedback if you decide to revisit the API for Mylyn 3.0, and not something that I appreciate is going to change any time soon.