Kent Watsen <[email protected]> writes: >> On Jan 3, 2024, at 4:58 AM, Ladislav Lhotka <[email protected]> wrote: >> >> Kent Watsen <[email protected] <mailto:[email protected]>> writes: >> >>> Thanks Lada! >>> >>> >>>> On Jan 2, 2024, at 6:50 AM, Ladislav Lhotka <[email protected]> wrote: >>>> >>>> Hi Kent, >>>> >>>> it's not exactly what you are asking for but FWIW Yangson has a method >>>> DataModel.schema_digest [1] >>>> that returns a “schema digest” - a JS object that contains all information >>>> that is necessary for such a client-side web app - data tree structure, >>>> types, restrictions and more. I used it successfully for writing a >>>> RESTCONF client app in AngularJS. >>>> >>> >>>> [1] >>>> https://yangson.labs.nic.cz/datamodel.html#yangson.datamodel.DataModel.schema_digest >>> >>> I can’t believe I didn’t know the importance of this method before. >>> - an opportunity to improve the docs? >> >> Do you have any suggestions? > > Sure. Something along these lines? > > OLD: Generate digest of the data model schema. This information is primarily > intended to aid client applications. > > NEW: Generate a digest of the data model schema. The digest is a flattened > and compressed view intended to enable processing the data model without a > full YANG processing stack, e.g., a single-page application written in > Javascript running in a web browser.
OK, will use, thanks. > > > >>> You’re right that it isn’t what was asked for, but it may very well be >>> sufficient… >>> - especially given that you said your AngularJS project was successful. >> >> YANG schema info is also needed in other parts of such an app, e.g. in HTML >> templates. > > Can you say a bit more here? By “YANG schema”, do you mean the schema digest > in particular? Why would there be HTML templates if dynamically-generating > the layout? Yes, I meant the schema digest. Of course it's not necessary if you can generate the entire app from a YANG data model. My aim was to write a multi-purpose app that uses a data model (digest) as input and adjusts accordingly. Lada > > > >>>> I discussed this once with Martin Björklund and I think he mentioned that >>>> tail-f used something similar. Perhaps this could be an idea for >>>> standardizing - apart from web apps there are other restricted >>>> environments not well suited for dealing with all the complexity and >>>> modularity of YANG data models. >>> >>> I welcome opening a discussion into supporting SPAs on top of RESTCONF. >>> >>> One issue I foresee is folks thinking server-rendered UI is good enough. >>> I’d like to counter with three comments: >>> 1. Server-rendered takes more server-processing >>> - it is better to offload to client, right? >>> 2. RESTCONF is moving into the realm of applications (not network devices) >>> - several NMS/Controller systems have RESTCONF-based NBIs >>> - such apps want/need SPA UI to meet market-demand >>> 3. JS tooling to process YANG is nearly non-existent (but see [A] and [B] >>> - this sets a high-bar for every application >>> - also suggests a market-opportunity... >> >> 4. A server-side app is kinda "man in the middle", so you typically have to >> store credentials for accessing the devices on that web server. In contrast, >> a client-side app authenticates directly with the RESTCONF server. > > Indeed, that too. > > >> Lada > > K. > > -- Ladislav Lhotka <[email protected]> PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
