Agents attribute enhancement request (date, newlines, signer)

[artcathcl]

Early consumers (i.e. Bob) of our agent info have asked the following:

1. agentVersion.innards: this is a notes date/time value. Is there a way to make this a more human readable date/time string?
2. agentContent.script: newlines are being rendered as "\n". In CouchLSX, bob is showing newlines with double-backslashes: "\n", which he believes is the more common convention in JSON. Can this be updated to use the double backslash?
3. Is it possible to provide the name of the agent's signer?

[jesse-gallagher]

On the first point, the good news is that that is done as of last week, though it's probably associated with a bumped JNX version.

[artcathcl]

@lbrown1 we'll get Bob added to the repo too, but meanwhile, maybe you can share this update with him?

1. @jesse-gallagher says that item 1 was done about a week ago.
2. for item 2, given that Orchard goals have changed slightly (raw dump only, encapsulation being done by the consumer), it may make sense for this type of refinement to also be done by some consuming layer (e.g. either the encapsulation layer, or the "end" consumer)?
3. item 3 fix added just a few minutes ago

[artcathcl]

@BobBalaban @lbrown1 ... on item 2 ... we're not fully sure what the request for that is. "\n\n" can be seen when the original code has two newlines in it. Is that the case? Or are you asking about translating "\r\n" to "\n" to standardize on Linux-style line breaks?

[BobBalaban]

The issue is that actual newline (0xA) values are illegal in JSON (as are all non-printing control characters). I read (don't remember where exactly, but i could try to find it again if needed) that the "normal" convention for representing newlines in json is to convert them to the string "\n". There may be an issue consuming a representation like "\n" because some string packages won't handle it correctly. We can experiment further. As a side note, CouchLSX converts newlines to \n for storage in json format, and converts back to 0xa newlines on import into the LotusScript engine, which requires newlines as statement separators

[BobBalaban]

for CouchLSX I've been converting \r\n to a single \n, then converting to the text representation. Double newlines (\n) aren't a problem

[jesse-gallagher]

Hrm, are there places where we're emitting the 0xA value? It should all be properly emitted as \n currently (and likewise for other control characters). The way we're generating the JSON all goes through the Jackson generator, and I don't think we're just dumping unescaped strings into the output, but that'd be important to check if we are.

[BobBalaban]

No, that isn't the issue at all. So it's Jackson that's encoding 0xa as "\n"? I guess that would be tricky to override. I'll see if consuming it that way raises any problems

[jesse-gallagher]

Hmm, I suppose I'm missing something. To my knowledge, newlines coming out of our JSON generator use "\n" when serialized out, as they should. Something parsing it as incoming JSON data should generally handle that fine, like JSON.parse(someFetchedJson) or the like.

[lbrown1]

It looks like github has messed up the exact text of the request. While currently the JSON shows \n for new lines, we would like \\n if possible

[jesse-gallagher]

What's the process that's consuming the JSON? Maybe that'd help me see what the idea is. As it is, it seems like that change would make it indistinguishable from someone writing a literal "\n" in e.g. the body of a form. We could double-escape all escapes, but normal JSON processors would see them all as text forms of the slash-plus-character string and not escape codes.

[BobBalaban]

The problem arises when we have a bunch of newline-delimited LotusScript source in JSON format that we want to run. The encoded newlines (whether they be "\n"s or "\ \ n"s) have to be converted back to newline code point values (0x10) before handing the code off to the LotusScript engine (LSAlone, or embedded LS engine in Notes/Domino). That conversion (for example, it is done in C++ code in CouchLSX) is, I think, more awkward if there's only a single backslash.

Having said that, if it's hard to change the output format because it's hidden by Jackson, then we can probably live with it as is bob

From: Jesse Gallagher @. Sent: Friday, October 15, 2021 10:50 AM To: HCL-TECH-SOFTWARE/domino-jnx @.> Cc: Bob Balaban [External] @.>; Mention @.> Subject: Re: [HCL-TECH-SOFTWARE/domino-jnx] Agents attribute enhancement request (date, newlines, signer) (#205)

[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don't click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]

What's the process that's consuming the JSON? Maybe that'd help me see what the idea is. As it is, it seems like that change would make it indistinguishable from someone writing a literal "\n" in e.g. the body of a form. We could double-escape all escapes, but normal JSON processors would see them all as text forms of the slash-plus-character string and not escape codes.

- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FHCL-TECH-SOFTWARE%2Fdomino-jnx%2Fissues%2F205%23issuecomment-944362820&data=04%7C01%7Cbob.balaban%40hcl.com%7C1a33a62e9ef344bccd5108d98feb05a0%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637699061840302714%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BOnTyfGZV3OfXGTHqo7o3zS%2FlSW22lzdemqIwYugwcE%3D&reserved=0, or unsubscribehttps://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAQ7W5I5DLX4VHPVNDCTVASDUHA5QHANCNFSM5FX4PGAQ&data=04%7C01%7Cbob.balaban%40hcl.com%7C1a33a62e9ef344bccd5108d98feb05a0%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637699061840312675%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kRzNCgnZlgQkPRTvTa9YwWRsyKrAh5Hc0CHZF3LE9e4%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Cbob.balaban%40hcl.com%7C1a33a62e9ef344bccd5108d98feb05a0%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637699061840312675%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4vG3GokHpzRdos9pvAyAC%2BQ9byjI%2BSP4zH6pQTx8RK4%3D&reserved=0 or Androidhttps://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Cbob.balaban%40hcl.com%7C1a33a62e9ef344bccd5108d98feb05a0%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637699061840312675%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BIOOTVL7dx2OpRi%2BVtQEchOEsh5GCbpbFVQxi73iR8k%3D&reserved=0.

::DISCLAIMER::

---

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.

---