New objects are not always new

Sometimes, the broker needs to report the existence of objects which are not new: when asked to do so by display, or when asked to load a file which already has been loaded.

A simple way to do this is to add a new attribute to the newobj message:

newobj = element newobj {
            proverid_attr,
            srcid_attr, 
            objid_attr, 
            exprev_attr?,
            attribute objposition { objid } ?,
            objtype_attr ?,
            attribute objparent { objid }?,
            attribute objstate { objstate },
            (properscriptcmd | unparseable) }

exprev_attr = attribute existedpreviously { xsd:boolean}

Cleaner, but not backwards compatible would be to rename newobj to obj and add an attribute new {xsd:boolean} (not optional!) to reflect this behaviour.

Suggestion here is to first add the attribute, then think about the other change.

Neither are source files

Very much the same discussion applies to source files. The relevant messages here are

newfile       = element newfile  { proverid_attr, srcid_attr, url_attr }
filestatus    = element filestatus  { proverid_attr, srcid_attr, newstatus_attr, 
                  datetime_attr} 
newstatus_attr = attribute newstatus { "saved" | "changed" | "discarded" }

Again, a backwards compatible first fix would be to include the exprev_attr, but in the longer run, we might perhaps just want a file message with a non-optional new attribute as above. Or we can even add a newstatus_attr "new", and unify all in filestatus. (Seems to leave a bit too much guesswork for displays?)

-- ChristophLueth - 28 Sep 2006

Discussion

This seems fine but I'm not sure why the display really needs to care whether the Broker considers the object to be new or not? My display implements a hash table of objects for each file. If it loses the hash table (file was closed in the editor) it wants to request information about the objects again if the file is re-opened. So the objects will be new from the display's point of view. Similarly for the file itself.

On the other hand, if all connected displays receive the new object messages (I forget if the Broker broadcasts messages to all displays or sends them individually), I see a reason. Displays that already know about a particular file should ignore not-really-new newfile and not-really-new newobj messages --- they could just check for duplicated ids and ignore them but having an explicit indication is cleaner. Is that the reason for wanting the flags?

In any case, we could use this as a handy debug mechanism to check consistency between objects in Broker and display and this seems a good enough reason itself.

So I'm in favour of adding the extra information. Using the optional attribute flag (I would call them both reload) means that displays can ignore the information if they're bold: the broker shouldn't tell us about reloads unless we ask (or unless it's broadcasting blindly to everyone).

-- DavidAspinall - 29 Sep 2006