[x3d-public] Data logging support in X3Dv4

Wed Oct 16 16:56:52 PDT 2019

Dick and I discussed Logger in some detail today.  Here are our updates to the mantis issue.  Review and improvements welcome

=======================================
Spec editor discussion: adding type "XFAny" is vague and somewhat problematic.

   XFAny [in] write

Preferred name would be more descriptive, such as "logValue" for example.

This field represents an exhaustive set of explicitly defined input fields for all types, e.g.

   SFBool [in] logValue
   MFBool [in] logValue
   SFInt32 [in] logValue
   MFInt32 [in] logValue
   SFFloat [in] logValue
… and so on.

Authors don't perform type conversion, the Logger does type conversion. The specification prose needs to clearly reflect this. Perhaps each and every type needs to be listed so that no confusion is possible.

=======================================

More detail is needed on output format. This is the primary value of log files, they are readable.

Multiple levels is counterproductive. Single format needs to be consistently provided, so that parsing and analysis is consistently possible. Output strings need to be legal values corresponding to each type (for example, SFTime is a double-precision float). Values are separated by a comma (with no whitespace). Comments are allowed for clarity. Examples:

# timestamp, sending node type, DEF name, field name, field type, field value

9876432.10,Material,myMaterial,diffuseColor,SFColor,0.1 0.2 0.3
9876432.20,Text,myTextNode,string,MFString,'"Hello" "Cruel,Comma"'

=======================================

Corresponding SAI Browser service does not need to be defined, since an author might have multiple Logger nodes active.

Design question with security consideration:
a. do multiple Logger nodes each use a different file, or
b. does Logger need a name, which gets prefixed to the output string above?

Also: the Logger node signature needs an output field so that authors can have access to the log entry, allowing authors to inspect or display what is getting logged.  For example:

   SFString [out] logEntry

Besides being a useful capability, not being able to see what is written is a security shortcoming.

=======================================

On 10/16/2019 8:31 AM, Brutzman, Donald (Don) (CIV) wrote:
> Thank you very much for this detailed information Michalis.
> 
> I have created Mantis issue 1263 to track this.
> 
> * https://www.web3d.org/member-only/mantis/view.php?id=1263
> 
> Who would like to take charge of the issue:  Next steps include:
> 
> - reconciling implementations X3DOM, Castle Game Engine and adding others (X_ITE, FreeWrl, etc.),
> - one or two example scenes (with outputs) to confirm conformance,
> - draft specification prose, including security considerations.
> 
> We can all assist via the mailing list.  Having someone in charge will help.
> 
> On 10/14/2019 11:58 PM, Michalis Kamburelis wrote:
>> Hi,
>>
>> Instant Reality and Castle Game Engine implement a "Logger" node, that
>> seems in line with your thinking :) It was indeed quite useful in some
>> cases when I wasn't sure what/when events are generated by something.
>>
>> See:
>> - https://doc.instantreality.org/documentation/nodetype/Logger/ ( note
>> that the CSS of Instant Reality docs seems broken for me now, but the
>> content is readable anyway)
>> - https://castle-engine.io/x3d_extensions.php#section_ext_logger (
>> it's a long page, look at section about "Logger" )
>>
>> The principle is simple: route *anything* to Logger's "write" field to
>> output it to browser-specific log mechanism. A special type is
>> invented here to allow an input event to receive any X3D field type:
>> XFAny .
>>
>> I would say that adding it to X3D spec may be reasonable (but without
>> the "logFile" field), in the "Event Utilities" component --
>> implementing this node is rather easy, and the usefulness is real.
>>
>> Example in classic encoding:
>>
>> ```
>> DEF MyLogger Logger {
>>     level 3
>> }
>> DEF MyKeySensor KeySensor { }
>> ROUTE MyKeySensor.keyPress TO MyLogger.write
>> ```
>>
>> Complete example that works in view3dscene:
>> https://github.com/castle-engine/demo-models/blob/master/x3d/castle_extensions/logger.x3dv
>>
>> Regards,
>> Michalis
>>
>> pon., 14 paź 2019 o 19:24 Brutzman, Donald (Don) (CIV)
>> <brutzman at nps.edu> napisał(a):
>>>
>>> [We explored several points such as this during today's Web3DUX User Experience teleconference.]
>>>
>>> Data logging is a common prerequisite for many types of measurement and assessment.
>>>
>>> Conventions for logging via HTML and also directly via X3D need to be considered. For example, numerous X3D sensor nodes include the ability to generate output events triggered by user navigation and interaction.  Common data formatting that identifies system parameters, event source, timestamp and data streams for a given scene can facilitate analysis.  Defining and adding a logging function to the X3D Browser object specification can enable secure recording of information.
>>>
>>> Question: do others think that logging is important also?  Am thinking that having such a capability is important for measurable improvements in X3Dv4.
>>>
>>> all the best, Don
>>> --
>>> Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
>>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
>>> X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
>>> _______________________________________________
>>> x3d-public mailing list
>>> x3d-public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> 
> 
> all the best, Don
> 

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman