On 09.04.2019 17:38, Moritz Hoffmann wrote:
> Well, the Java scripting framework will always use a Reader, which decodes
> the input according to
> the current Charset. I don't see a way to circumvent this, either by not
> using a Reader instance
> or by injecting a custom, non-adapting Charset. I agree with Rick that this
> is not a problem that
> ooRexx should solve. Instead, I'd base64-encode the scripts, and decode them
> before passing them
> to the interpreter. Base64 will survive any reasonable Java byte decoding
> magic.
The reason why it is a request (and not an error report ;) ) is that so far the
binary
representation has not caused a problem, because only Rexx would create and
later read the
self-produced tokenized code (knowing its internal structure and the binary
data part).
Now, that Rexx scripts get deployed in an environment that only processes text
and not binary data
(in this case the Java scripting frameworks) and there are use-cases (whenever
java.io.Reader gets
triggered in the scripting frameworks) that cannot be safely intercepted by
BSF4ooRexx, which
enables ooRexx to be hosted by and deployed from Java (applications) and also
making all of the Java
world available to ooRexx.
As this uncovered problem lies in the binary representation of the tokenized
Rexx code produced by
rexxc which in this use case turns out to be actually (and unexpectedly) a
quite fragile solution it
would nevertheless be solvable by having rexxc (or some postprocessing utility)
store it in form of
a pure text rendering. Hence this request addressed to ooRexx.
---
Ad Rick's idea to create a utiltity in BSF4ooRexx to recode the rexxc-produced
binary data in an
"immune" textual form (basically coding the binary data with c2x or base64) and
change BSF4ooRexx
internal (native) code to deal with this situation has the following
implications:
* the 'rexxc' generated and postprocessed tokenized format is then not
compatible with Rexx anymore,
* hence submitting such a non-compatible text-encoded version of the
tokenized format would not be
processable by Rexx,
* every Rexx programmer who wishes to use Rexx as a scripting language for
Java applications or
uses BSF4ooRexx to create demanding applications in pure ooRexx using Java
classes for missing
ooRexx features (like portable GUIs, but also IPV6-socket connections or
ssl-connections, etc.)
would need to know that for sheltering their Rexx code they must
o run 'rexxc' on each script,
o plus must not forget to run the BSF4ooRexx postprocessing script
applied on those freshly
produced 'rexxc' tokenized scripts,
o deploy the postprocessed versions (*not* the original and Rexx
compatible 'rexxc' tokenized
version)
* now take into account that application systems need to be maintained in a
constant manner
possibly by different programmers, each maintenance change causes the need
to 'rexxc' and in
addition to apply the non-ooRexx utility to postprocess the tokenized code
to turn it into pure
7-bit text; adding another step, making it more cumbersome and therefore
over time mostlikely
more error-prone.
If it was possible to encode the tokenized form rexxc currently produces in an
agreed upon format as
text then ooRexx could process such a version by converting it back into its
binary form, and
proceed with the resulting data as today. In this scenario one would not create
a non-compatible
version of a tokenized Rexx program, but rather one that ooRexx would be able
to execute without the
help of any other tool.
This is just thinking loud about the situation and the idea of creating a
non-ooRexx compatible
tokenized version of Rexx programs in the file system.
(Still have to think about it.)
---rony
>
> On Tue, Apr 9, 2019 at 3:34 PM Rony G. Flatscher <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 09.04.2019 15:13, Rick McGuire wrote:
> > And it doesn't make sense to put the onus on solving this on the
> interpreter. If it is
> desired to
> > store binary code in an inherently text-based interface, then
> BSF4ooRexx should handle this be
> > including a utility to perform the transform and then decoding the
> format before passing it
> to the
> > interpreter.
>
> Well, please tell IBM, Oracle and the OpenJDK community which devised and
> applied all of the Java
> scripting frameworks in the past twenty years such that they expect
> scripts to be supplied as text
> only, not as binary data.
>
> If a Java program employs e.g. the "javax.script" framework and it is
> supplied the name of a Rexx
> program file, the "javax.script" framework will use some "java.io.Reader"
> to read the script from
> the file. In the case of rexxc-tokenized Rexx code the Reader will
> inadvertently destroy the
> binary
> data due to possible codepage translations well before BSF4ooRexx
> receives the (then ruined
> binary)
> script data.
>
> There is nothing, BSF4ooRexx could do here as it exploits/applies and
> depends on the Java
> scripting
> frameworks, unfortunately.
>
> Hence asking ooRexx to the rescue; suggesting to add a single step
> before storing the rexxc
> produced binary data by turning the binary data into a hexadecimal string
> and store that lossless
> rendering; and upon receiving a tokenized Rexx program adding a single
> reverse step to turn the
> hexadecimal string losslessly back into the needed binary form for
> unflatening.
>
> ---rony
>
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
