Andreas Meissner wrote:

Hi,

is there a possibility to get notified about recent server-side changes
so that the client ui can adjust accordingly? Does that have to be done
with the mentioned Feed Service? If yes, where would be a good starting
point to investigate that?

It doesn't have to be done with the feed service, but depending on your
needs, the feed service could be useful. There is a wiki about the
FeedService here: https://jazz.net/wiki/bin/view/Main/FeedService

Besides, what is the recommended way to update client ui after changes
initiated by the same client. Is there already a observer mechanism
available where ui elements can register listener or fire changes?

I think you should take a look at IItemManager. This is a client-side
cache that allows multiple participants on the client (e.g. independent
views) to share items such that when one participant fetches a newer
state, everyone holding the shared item sees the new information. There
is an observer mechanism - see the addItemChangeListener methods. The
javadoc on IItemManager is pretty extensive. The only thing I'll add
(because I saw someone get stuck on this recently) is that you get the
IItemManager by calling ITeamRepository.itemManager() (note the
non-javabean naming pattern).

Andreas Meissner wrote:

Hi Chris,

thanks for the hints! That seems to be exactly what I was looking for.

It doesn't have to be done with the feed service, but depending on
your needs, the feed service could be useful.

Just for curiosity, what would be other possibilities?

Sorry, that wasn't very clear. Here is some more detail: One thing you
will not find is a mechanism by which the client registers to be
contacted directly by the server when an event happens. Clients always
discover new information by polling the server.

The client polling for new information could be accomplished by
refreshing a feed or using the item manager with the REFRESH flag as I
mentioned before. But both of these mechanisms are build on top of Jazz
services. Any time a client invokes a service method it could result in
new information coming back to the client. So "other possibilities"
would amount to calling some arbitrary service (possibly one you
implement) that returns new information to the client.

However in terms of scalability, using the feed service is the best way
to make clients aware of events. This is because the feeds are
implemented as RSS or Atom and these can make use of HTTP caching to
reduce load on the server (whereas using item manager refreshes or
polling arbitrary services frequently for event information will start
to look like a denial of service attack to the server if lots of clients
are polling very frequently).

Another thing that's worth mentioning here is the typical relationship
between services, client libraries and the item manager. Some services
are only meant to be used by other services (on the server), but if you
implement a service that you want to use from an Eclipse client you
should implement a client library for it. As you implement your client
library you should think about "feeding" the item manager (by calling
applyItemUpdates() and the other apply* methods) as items pass through
your client library code so that holders of shared items have access to
the new information your client library is receiving or producing.

--
Chris Daly
Jazz Component Development Team