putting a relative large amount of data in 1 line into a field :^)

[Dar Scott]

On Thursday, June 26, 2003, at 07:22 AM, wouter wrote:

> All this is why I suggested in one of the bugreports to add something 
> like a "binary" field to Metacard.
>
In most cases a custom property in the owner of the potential field 
might be more appropriate.  (The question I brought up earlier this 
week on per-card non-displayed background data, takes a wee bit more 
thinking.)

If a field is used, then using base64Encode() and base64Decode() to 
format the data should allow it to work for storage, even under today's 
conditions.  If you prefer hex, you should be able to roll your own hex 
encoding using binaryEncode() and binaryDecode(), which might be more 
convenient for debugging.  Preview copies of my free "boxes" library 
are out and I hope to announce that soon; it will allow complex data to 
be put into fields, but field storage is best suited for debugging.

Given that...

I think good handling of long words in wrapping is desirable and it may 
not even need a special mode.

And even though I don't like the idea of storing binary data in a 
field, it might be done in quick debugging lines and we might do it 
accidently, so I would support something reasonable happening.  This 
means that nothing weird happens with null (or any other control 
characters).  This means no line limit.  This means wrapping works for 
any kind of data.  This means no crashing.  Even with unicode.  This 
means documentation warnings can be removed.  There would be no need 
for a "binary" field under these conditions.

I don't know how efficient field storage is.  It might be that if there 
are no unicode characters and there are no per-char properties set that 
it is relatively efficient.  Even so, I would think a custom property 
would be more efficient as far as space and speed, but I don't know for 
sure.

Dar Scott