[MOBY-dev] RFC #1941: Data returned by xxx_async and xxx_poll

[Johan Karlsson]

This is really one of the hot-points. Should we wrap this data in 
mobyStatus or in mobyData? It really comes down to a question of 
viewpoints (both ways would be possible to implement).

(btw, sorry if we mix the terms "event" and "status" but we are talking 
about, in this context, the same information (mobyStatus vs Event-base 
class)

Just to summarize what (we think) Martin is suggesting:

=====

He suggests that we do not need mobyStatus and instead the status 
information should be put in normal Moby objects, all registered in the 
shared Moby object ontology. The methods _async and _poll would return 
mobyObjects instead of mobyStatus. These mobyObjects would have the same 
information as is in mobyStatus (asyncID, LSAE status XML etc). The 
mobyObjects for this would also be ordered in the moby object ontology 
(placed in a hierarchy, separate subtree).

Some comments from Martin:

(1) We should change the API/protocol as little as possible (more of a 
general comment).
(2) There could be services that would like to register with such 
mobyObjects.
(3) Service providers could easily register new such mobyObjects and 
inherit (extend) existing status mobyObjects (all new status objects 
must inherit the base-object Event).

=====

Martin, please correct us if we misunderstood something.

Now, let us try to explain our position (which is to keep mobyStatus):

We do not want to put such information in mobyObjects because it would 
mean that we put what is really status (event) information about jobs in 
the Moby object ontology. It is difficult enough to maintain a good 
ontology but, at least, let us keep the biomoby ontology for objects 
related to biological information (results belonging in the domain). 
This is a very important principle.

(1) Martin is correct that our mobyStatus alters the protocol more (the 
new async clients would need to handle the tag) than putting the 
information as mobyObjects.

However, the only clients and services that would be affected by the 
alteration (mobyStatus) would be asynchronous clients and services 
("new" services/clients, or at least new "interfaces"). Old clients 
would never receive or send mobyStatus content, so they would not be 
affected by it. In our opinion, it is better to create new placeholders 
(mobyStatus) for such new and different information than to put it where 
it does not belong (the ontology). The protocol would only be altered 
for this new type of communication, not for the "standard" communication 
(which would still be available).

(2) We have a hard time imagining such services. Martin, could you give 
some examples?

(3) By using "standard" LSAE in our approach (mobyStatus), new events 
can be extended from existing events (but as we will explain, this 
should, if possible, be avoided), so the possibility to extend events is 
not an argument in itself to put this information in the moby object 
ontology.

If the events are placed as mobyObjects in the ontology, new events 
would be instantly shared by all clients (but of course, the clients 
would not understand the new, added, attributes unless there are changes 
in their implementation). Same thing is possible with mobyStatus and 
LSAE, but the changes would not be "shared", at least not directly.

The five basic event types (Heartbeat_event, Percent_progress_event, 
State_changed_event,  Step_progress_event and Time_progress_event) in 
LSAE covers most (if not all) situations.

We are proposing that the only status messages all async clients _must_ 
understand are the ones specified already in LSAE. If a service provider 
needs to define new status messages by extending already existing, they 
run the risk of clients not understanding their new status messages (at 
all).

In the LSAE specification, it even says that clients should simply 
ignore new status/events that they do not understand. Only specialized 
clients would in this scenario be able to understand the new 
status/events (that would come from a very specialized service).

If, in the future, there is a need for new "standard" event types, this 
could be carefully considered (in this mailing list for example) and 
added to the official documentation/API. While this is a simpler and 
slower mechanism than what Martin suggests, it is also a more _stable_ 
mechanism than ordering the events in a dynamic, uncontrolled and shared 
hierarchy. MobyStatus and LSAE events still do what we need, but in a 
more stable and controlled way.

While mobyStatus would need to be handled by new async clients, it does 
not  complicate future client tooling to have a stable interface, does it?

Kind regards,
Johan