> There's nothing comparable to a media type for the results that appear
> From p:exec, so without an extra flag somewhere, I don't think p:exec
> can do anything useful. (A quick peek at XML Calabash reveals that it
> treats anything that isn't XML as if it was text and attempts to encode
> the bytes.)
>
> I suppose that with a set of "*-as-binary" attributes, the results
> could be base64 encoded (and the input(s) base64 decoded, I suppose).
>
> My two cents:
>
> 1. I think the step is implicitly geared towards text outputs, not
> binary.
Agreed.
> We don't say anything about binary and "wrap-result-lines" suggests
> pretty
> strongly that we didn't think about it.
That was my impression as well. I was actually looking for a dynamic error for the case when the result data cannot be represented as text - and was surprised when I found none.
> 2. Even if we had a good story on binary, you'd need some sort of a
> flag
> to tell the step to treat the result as binary.
That would be the best solution, but a dynamic error on binary data might be OK well.
Regards,
Vojtech
--
Vojtech Toman
Consultant Software Engineer
EMC | Information Intelligence Group
vojtech.toman@emc.comhttp://developer.emc.com/xmltech