Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 353458

Summary:	[api] support repositories with push-model
Product:	z_Archived	Reporter:	Thomas Ehrnhoefer <thomas.ehrnhoefer>
Component:	Mylyn	Assignee:	Project Inbox <mylyn-triaged>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P1	CC:	leo.dos.santos, robert.elves, shawn.minto, steffen.pingel
Version:	unspecified	Keywords:	plan
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:
Bug Depends on:	291252, 363354
Bug Blocks:	281893

Description Thomas Ehrnhoefer

2011-07-30 18:23:12 EDT

Some repositories have an (optional) push model for retrieving task updates. If that's enabled Mylyn should:
* have API for a client to "push" a TaskDataCollector or updated taskData to the framework
* don't sync queries automatically if the push-mode is enabled 

As far as I can tell, there is no support for this currently. Workarounds I can think of:
# run a SyncTaskJob each time the server notifies the connector of a change to a task
** connector needs to save the state that for this one task a syncJob was triggerd (and save the taskData retrieved from the server locally)
** if the getTaskData gets called, reset that state, and instead of pinging the server just return the previously saved taskData
# just call taskDataManager.putUpdatedTaskData when the server pushes a state

Not sure if/how we could better support this in the framework, maybe the second alternative is already the right way to do this anyway. There should at least be support to enable/disable query auto update for each repository I think.

Comment 1 Steffen Pingel

2011-08-12 11:34:51 EDT

Thanks for the request. Some discussion around this can be found on bug 291252.

I agree that we should provide a synchronization API that supports a push-based approach. A key component that is currently missing is an entity that manages the state that needs to be synchronized with the repository. This state needs to be shared with the connector. This would enable a connector to notify the tasks framework of relevant changes.

Comment 2 Thomas Ehrnhoefer

2012-01-16 11:12:53 EST

A related effort is supporting event-based APIs.
More and more ALM tools provider an event feed that usually is a lot more lightweight than querying, but at the same time most of the time does not allow filtering.

Connectors could poll those event streams more often than run queries, but as soon as an event occurs, most likely a query has to be run (to determine if the change affects any item in a query). This could lead to a potentially high number of queries when changes happen frequently, so some sort of delay has to happen.

Also, some event streams contain changes (delta), some full task details, some just identifiers. Finding a proper API sounds challenging to support this, but given what I have seen in terms of performance in three different systems (one REST, one SOAP, one SDK), what they have in common is that the event feeds perform a lot better.

What I have done in the past to support this is to have a constant polling (with a delay) of the event feed, do some brief parsing of the event to make sure it's important to the connector, then check with tasks are affected. And whether I have the task already or not, I always invoke all queries of that repository (some Events are scoped by project, so the queries to run can be limited a bit) to make sure I capture the change correctly.

Comment 3 Sam Davis

2016-04-05 17:36:31 EDT

Closing as part of backlog cleanup. Please reopen if you are working on this.