[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:	DECmcc user notes file. Does not replace IPMT.
Notice:	Use IPMT for problems. Newsletter location in note 6187
Moderator:	TAEC::BEROUD

Created:	Mon Aug 21 1989
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	6497
Total number of notes:	27359

367.0. "PROBLEM: Refreshing the Iconic PM's view of the Universe" by COOKIE::KITTELL (Richard - Architected Info Mgmt) Sun Sep 30 1990 16:07

When an instance is deleted through the Iconic PM, the Icon or child name is
removed from the map window. But when instances are deleted by other means,
such as FCL or by the operation of some directive, there doesn't seem to be
a way to refresh the Map window.

For instance, in our proto model, data objects (files, volumes, and databases)
can be either the child of Node Storage or Archive. The Archive directive
"moves" a data object entity from Node Storage to the Archive. Inside,
the Archive directive creates a child of Archive and deletes the child
of Node Storage. The Retrieve directive moves the data object back to
Node Storage by the same mechanism.

It appears that the Iconic PM caches the list of instances, such that after
an Archive directive has deleted the child of Node Storage, double-clicking
on the child class still displays the child, even though it isn't there
anymore. The classic cache-coherency problem. Even doing a look-up and
coming back down, the phantom child is still there.

A refresh operation for the map window would help, but would presume the
user has noticed something doesn't look right, for him to have the motivation
to select it. Have you got something up your sleeves to keep the map
window in sync?

T.R	Title	User	Personal Name	Date	Lines
367.1		TOOK::F_MESSINGER		`Mon Oct 01 1990 11:53`	8
	re -.1 Very good characterization, Rich! There IS a cache coherency problem. We were planning on an "update" menu selection...we'll see how it goes. Fred
367.2	Future refresh capability	MAVIC::D_MOORE		`Tue Oct 02 1990 14:53`	22
	There are two mechanisms that were defined, but will not show up in V1.1. - Update item in the File menu of a Map Window: This feature, whether at the global or child entity level, would go out and "SHOW" again to pick up any entities added or deleted at that level. We could not update the "map" (as in reading in the map file for the domain) because any edits made in the current map window would be lost. We could put up a message saying "the map has been changed, do you want to save it? YES/NO?", but if you saved the map file and then read it in, you would get the same thing. This would be useful mostly at the child entity level. - Watch for changes in the opened domain and automatically make changes: This would be at the global -- domain -- level only. In the future we will use the MCC events mechanisms to find out when a new domain member has been added or deleted. If the member was added, we would autoplace it on the map. - Dave
367.3	A vote for cachelessness over stale data	COOKIE::KITTELL	Richard - Architected Info Mgmt	`Wed Oct 17 1990 21:28`	36
	RE: .1 Dave, I'm sorry, but I gotta whine about this one. What it sounds like you are planning on doing is putting a cache in V1.1 and fixing it so it doesn't lie in a future version. Caches are a performance optimization, and shouldn't affect the correct operation of the system. If you provide an update button, you are at least signalling the user that what he sees may be out of date and you provide a way to update his view. Something with finer granularity would be to interpret a click on the entity name to be a request to refresh the list of instances below it. Once you add that button, see if there is any way our access module can "push" it for the user, since we will know when we potentially invalidate his view. Since the AM won't know what he is looking at, perhaps an event could be defined, which we trigger whenever we create or delete an entity as a side-effect of an operation. If the information applies to cached data you update the cache and the window, otherwise you ignore it. But the way it is right now, once we do an operation that invalidates what is in a map window, we have found no way short of completely closing up to the top-level domain and then starting over to get an accurate view. If you can't get some sort of refresh mechanism in, see if you can sneak in a bit in the logical to turn off the cache. For our purposes, it looks like it would be better to not cache the child instance information, and look them up each time a window is displayed, than to have no way of showing our user what is really out there. Let me know if you think there's any hope for something in the V1.1 timeframe. Thanks.