[x3d-public] Data logging support in X3Dv4
GPU Group
gpugroup at gmail.com
Fri Oct 25 06:33:40 PDT 2019
freewrl x3d parser ignores attributes it doesn't recognize / hasn't
implemented.
- so no backward compatibility issues with logging or width, height
attributes
-Doug
On Thu, Oct 24, 2019 at 7:29 PM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:
> Thanks for the great example - impressive!
>
> Getting explicit to match your description, it looks like the key
> statement is
>
> <X3D id="x3d" showLog="true" logLevel='5' width="800px"
> height="600px">
>
> Adding it to X3D root would seem to work for X3D applications in a
> non-HTML context as well. Also makes it easy for any author, and possible
> for any model (not requiring Script node). Thus meets goal of easy
> repeatability too.
>
> Is this approach (attributes on X3D root) acceptable with everyone,
> including FreeWrl view3dscene and other standalone application environments?
>
> If so, wondering if we are ready to tackle other attributes on X3D element
> (such as id width height url)?
>
> Once we agree on basic approach, we should also discuss whether scoping of
> logging is possible. Can it be turned off for parts of scene graph, does
> it affect internals within Inline and ProtoInstance, etc.
>
> Good topic for issue review on X3D Working Group call Friday morning.
> Participating in the discussion and email feedback are both welcome.
>
> v/r Don
>
>
> On 10/20/2019 3:18 PM, Andreas Plesch wrote:
> > Here is an example implementation using a new attribute 'logLevel' to
> > the X3D element, working as a browser property interface>
> >
> https://raw.githack.com/andreasplesch/x3dom/dcde5c67281c1a3dae6b20b1944065d24d369711/test/functional/widgetPlaneSensor.html
> >
> > logLevels 5 and higher turn on event logging.
> >
> > [For x3dom it may make sense to reserve lower levels for system level
> > logging: exceptions, errors, warnings, information]
> >
> > The format here is FROM node type, node def name (or null), field
> > name, field value
> >
> > Perhaps it suffices to just focus on the ROUTE level logging since
> > these events are usually the only one of interest.
> >
> > The 'trace' attribute in x_ite_dom has a similar effect (except not
> > restricted to ROUTEd events).
> >
> > So two implementations of such a logging feature may not be out of reach.
> >
> > -Andreas
> >
> > On Sun, Oct 20, 2019 at 3:58 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
> >>
> >> On Sat, Oct 19, 2019 at 2:04 AM Brutzman, Donald (Don) (CIV)
> >> <brutzman at nps.edu> wrote:
> >>>
> >>> Thanks for the great analysis Andreas.
> >>>
> >>> Sorry for mystery assignment... we do need someone to take charge of
> this one. Can defer to someone else if you prefer.
> >>>
> >>> There is much to be said for Logger staying directly aligned with
> Browser services. But, if that is where we leave it, am expecting that
> logging will be rarely used because use of Browser services requires a
> Script node and adaptation code - tedious and inconsistent. Much better
> for encouraging use is to also have a consistently defined Logger node that
> any author can configure or ROUTE to, in any scene, for consistent testing
> and conformance/QA.
> >>
> >> I would envision logging to be a browser feature which can be set in
> >> the browser interface, or as a PARAM for html as other browser
> >> properties:
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#BrowserProperties
> .
> >> x3dom uses an Environment node to set various Browser options. It
> >> would be very easy to use. The point is that it is easier to use than
> >> a Logger node because it would not require modifying the content of
> >> the scene.
> >>
> >> The browser option would be make a Logger node unnecessary. So the
> >> spec. would not have to define a Logger node.
> >>
> >>>
> >>> Quote: "when you come to the fork in the road, take it" - Yogi Berra
> >>>
> >>> Hmmm, I guess we need to put such a Logger node in Core profile for
> full generality and usefulness.
> >>>
> >>> Are you saying that logLevel is for automatic logging of all events,
> rather than explicitly ROUTEd input values? Interesting possibility... if
> so, once again we might achieve best of both worlds by having one logLevel
> setting be for ROUTEd input values only. That would seem to give authors
> both simple flexibility and fine-grained control.
> >>
> >> Yes. Only ROUTEd events was one of the LogLevels I had listed (the
> first one).
> >>
> >>>
> >>> Am willing to create a Prototype that at least creates a Script node
> console log illustrating proper text outputs. (File saving not allowed in
> Script node sandbox.)
> >>
> >> That would be useful in any case.
> >>
> >>>
> >>> Looks like the variations of logging support desired for a given model
> can all be expressed in the Logger node itself, meaning that we wouldn't
> have to modify any X3D/head/Scene parameters. Simple is good.
> >>
> >> Yes, but it is even simpler to not have to have a Logger node. It
> >> would be just a matter of switching on Logging in the browser. No
> >> scripting required.
> >>
> >> Best, -Andreas
> >>
> >>>
> >>> I agree that we seem to be getting closer on this one.
> >>>
> >>> On 10/18/2019 12:08 PM, Andreas Plesch wrote:
> >>>> I received a mystery email from the Mantis tracker about being
> >>>> assigned a Logger entry. The forwarded Mantis summary seems pretty
> >>>> comprehensive. It focuses on a Logger node.
> >>>>
> >>>> Another way to think about logging of events is as a browser feature
> >>>> which can be enabled, parallel to a debugger. This is how I would
> >>>> first think about logging. As a system feature, not as a scene content
> >>>> feature. It seems counterproductive to have to modify/augment a scene
> >>>> with extra nodes, scripts and routes to enable logging.
> >>>>
> >>>> So my suggestions would be to turn this into a Browser Property or
> >>>> Browser Option. Scene's could hint with a SAI script what level of
> >>>> logging they allow, expecting the browser to respect the hint. Note
> >>>> that a Logger node would not prevent browsers from unauthorized
> >>>> logging if a browser really wanted to.
> >>>>
> >>>> Is the main security concern that with logging an otherwise protected
> >>>> scene (perhaps by encryption) would expose its data (geometry, raw
> >>>> imagery) ?
> >>>>
> >>>> Enabled logging would just log output events by nodes selected by
> >>>> loglevel, always to the console (which may be recorded in a file
> >>>> anyways), in a standard format as outlined in the Mantis summary.
> >>>> Filtering can be applied by other tools. There are a lot of events
> >>>> zipping around.
> >>>>
> >>>> loglevels could be combinations of:
> >>>> - ROUTES: only events which go through routes
> >>>> - Sensors: events generated by any Sensor
> >>>> - Scripts: events generated by Scripts
> >>>> - Interpolators/Sequencers: events generated by those
> >>>> - component: events generated by all nodes defined in a component
> ("Networking")
> >>>> - all: deluge from all nodes
> >>>> - none: no logging, default
> >>>>
> >>>> I suppose one way to think about this as a browser feature is to have
> >>>> implicit Logger nodes and routes from all the nodes selected by
> >>>> loglevels. The advantage from a spec. perspective that the mechanism
> >>>> does not have to be explicitly prescribed, only the functionality.
> >>>>
> >>>> So I think it boils down to:
> >>>>
> >>>> a) What is the standard format of the logging output ? Perhaps easy
> to define.
> >>>>
> >>>> b) What is logged ? output events of some or all nodes.
> >>>>
> >>>> c) The browser service specification:
> >>>>
> >>>> - it may be possible to piggy back on setBrowserOption which uses this
> >>>> table:
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#t-BrowserProperties
> >>>> :
> >>>> add a property:
> >>>> Name: LogLevel
> >>>> Description: allow logging of events to console
> >>>> Range: see above
> >>>> Default: None
> >>>>
> >>>> And perhaps a header (meta?) entry 'maxLogLevel' in the Scene to limit
> >>>> logging, by a Scene author:
> >>>>
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/core.html#HeaderStatement
> .
> >>>> Or allow resetting of the Browser Option by the Scene with an
> >>>> initialize script.
> >>>>
> >>>> I think once a more precise spec. language is provided, multiple
> >>>> browser implementation could be quickly had.
> >>>>
> >>>> Any feedback welcome.
> >>>>
> >>>> -Andreas
> >>>>
> >>>> On Wed, Oct 16, 2019 at 10:27 PM Andreas Plesch <
> andreasplesch at gmail.com> wrote:
> >>>>>
> >>>>> x_ite_dom can log all out events by adding a 'trace' attribute to
> the x3dcanvas element.
> >>>>>
> >>>>> x3dom does not have built-in logging . Instead, all web browsers
> have powerful debuggers which can be used to follow the event flow (and all
> internals). Chrome even lets you modify code and then continue, or restart.
> >>>>>
> >>>>> This also applies to x_ite.
> >>>>>
> >>>>> Andreas
> >>>>>
> >>>>> ---on the phone---
> >>>>>
> >>>>> On Wed, Oct 16, 2019, 6:40 PM <x3d-public-request at web3d.org> wrote:
> >>>>>>
> >>>>>> Send x3d-public mailing list submissions to
> >>>>>> x3d-public at web3d.org
> >>>>>>
> >>>>>> To subscribe or unsubscribe via the World Wide Web, visit
> >>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >>>>>> or, via email, send a message with subject or body 'help' to
> >>>>>> x3d-public-request at web3d.org
> >>>>>>
> >>>>>> You can reach the person managing the list at
> >>>>>> x3d-public-owner at web3d.org
> >>>>>>
> >>>>>> When replying, please edit your Subject line so it is more specific
> >>>>>> than "Re: Contents of x3d-public digest..."
> >>>>>>
> >>>>>>
> >>>>>> Today's Topics:
> >>>>>>
> >>>>>> 1. Re: Data logging support in X3Dv4 (Brutzman, Donald (Don)
> (CIV))
> >>>>>>
> >>>>>>
> >>>>>>
> ----------------------------------------------------------------------
> >>>>>>
> >>>>>> Message: 1
> >>>>>> Date: Wed, 16 Oct 2019 15:31:25 +0000
> >>>>>> From: "Brutzman, Donald (Don) (CIV)" <brutzman at nps.edu>
> >>>>>> To: Michalis Kamburelis <michalis.kambi at gmail.com>
> >>>>>> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>, Feng
> Liu
> >>>>>> <LIU_F at mercer.edu>
> >>>>>> Subject: Re: [x3d-public] Data logging support in X3Dv4
> >>>>>> Message-ID: <2f511aa0-9a21-1fc6-7b36-3f43114186b1 at nps.edu>
> >>>>>> Content-Type: text/plain; charset="utf-8"
> >>>>>>
> >>>>>> 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
> >>>>>> --
> >>>>>> 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
> >>>>>>
> >>>>>> ------------------------------
> >>>>>>
> >>>>>> Subject: Digest Footer
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> x3d-public mailing list
> >>>>>> x3d-public at web3d.org
> >>>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >>>>>>
> >>>>>>
> >>>>>> ------------------------------
> >>>>>>
> >>>>>> End of x3d-public Digest, Vol 127, Issue 27
> >>>>>> *******************************************
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> 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
> >>
> >>
> >>
> >> --
> >> Andreas Plesch
> >> Waltham, MA 02453
> >
> >
> >
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20191025/67f68dd8/attachment-0001.html>
More information about the x3d-public
mailing list