> On Jan 3, 2024, at 4:58 AM, Ladislav Lhotka <ladis...@lhotka.name> wrote: > > Kent Watsen <kent+i...@watsen.net <mailto:kent+i...@watsen.net>> writes: > >> Thanks Lada! >> >> >>> On Jan 2, 2024, at 6:50 AM, Ladislav Lhotka <ladis...@lhotka.name> 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. >> 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? >>> 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.
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
