XTemp v0.84 - questions

[Marius Plavan <marius.edtf@gmail.com>]

Hi all,

I looked quickly through v0.84. I gathered a few questions based on that version which I would like to raise to the TaMIE TC. 
Some of them might question some fundamental concepts in the draft, with the sincere goal of improving the draft -- as I am one of the users of XTemp.

• "catch/@datetime: provide a VP-time for the catch that is different from the
  VP-time of the embedding scriplet. This makes it possible to query events
  that occurred before the scriplet VP-time. After the catch execution, the new
  VP-time of the executing scriplet will be set based on the latest of
  {scriplet VP-time before executing catch, date/time of the latest event [of
  the pattern] matched by the catch ."

• I might not see / understand the entire picture regarding the VP Time so clearly. But as little as I see in this moment, if I, as a user of XTemp, have the option of specifying catch/@datetime, that is enough for me to catch one or more events based on the time which was stamped by the engine. Additionally to the "event time" (stamped by the engine), the user might be more inclined on querying for events after their actual "business" time (i.e. when the event actually took place in the service under testing / monitoring, but which of course is something that's dependent on each service implementation).
  
• As I see it, a catch operator might move the scriplet's VP time backwards. What benefits has then the user, by having the concept of scriplet's VP-time, if it can be altered (both forward and backwards) by the three operators? Is it there mostly for assuming a given time for each catch operator (that does not have a @datetime specified by the user)? Is it there also for simulating "@concurrent" scriplet behavior?
  

• "The first "match" child element will be executed first on the event board". ...
  

"The X-effect of a catch is the sequence of selected events (or views of these, in case the related match statements have defined a view)."

• What I could not deduce from the draft is whether each match (inside a catch) will return the matched event immediately or only when catch execution will finish. For example, one might want perhaps to query in the second match the content of the first event (matched using the first match). This can of course be accomplished by using a second catch, but is it possible / intended to be achieved using more matches inside the same catch?

• Even if some things can be deduced by some of us, do you see a benefit in having also a section about error / exception handling in the draft? I feel that, if not addressed in the standard, this might cause in the future various interpretations by the engine developers. I target here mostly things that one or more engine implementations might take as granted when handling specific exception cases and which might impact portability of that script on another XTemp engine.
  
• As an example: What happens when catch (or any other extension function used by the engine) is waiting for an event for a large period, but for some reason the event adapter knows already that events are not going to arrive anymore (let's say that the network is done, and perhaps the event adapter - or another "entity" - might want to signal the engine that an environment exception was encountered - no disk space, no avail ram, crash)?
  
• One approach might be to (optionally?!) allow a return from the catch when such exceptions are encountered, and return the "exception event" to the script.
  
• Alternatively / additionally, one can add global "exception handlers" which can be reused in cases when the script-package is interacting with the outside world through the "engine" (and it cannot foresee all the exceptions that might occur).

• Is there a place where latest XTemp transformers can be freely accessed?
  
• I would like to use the latest XTemp transformers in edtf, if available. I have the eTSM transformer, but it is a few months old.
  
• No problem if it is a "development" version, as long as it is "workable" :-)
  

Kind regards,
Marius