How safe is this?

Hi Ron, as long as your parsing is perfect, I think this conversion
would be fine and platform independent.  I would be sure to test your
code works on numbers that do not have the high order bit set, since
this would result in a shorter-length of the represented number.  Niels
Ferguson and Bruce Schneier suggest using little-endian representations
of control fields in a secure-channel which is why, personally, I use
ByteArray>>#uint:at: and #uint:at:put: now provided by Cryptography.

As you know using Strings does introduce the potential for platform
dependencies; have you considered simply stopping at the ByteArray and
using binary?

  yourNumber asByteArray asInteger = yourNumber

Regards,
  Chris


--- Ron Teitelbaum <[hidden email]> wrote:

You know it's funny I was so busy thinking about transferring the smallest
possible strings I didn't even consider binary.  Very silly and much better
thanks!

Ron

Chris and All,

I was looking at ByteArray>>uint:at: and ByteArray>>uint:at:put: and from
what I'm seeing this is basically a way to add an int into a byteArray at a
given position?  

My 256 bit integer storage was

(ByteArray new: 32)uint: 256 at: 1 put: myInt and to get it back was
aByteArray unit: 256 at: 1.

Was there more to this then that?  One of the neat things I saw was
aByteArray, aByteArray  and aByteArray, 'abc' worked!

I had started using XML for context, and ran into serious problems with the
converted strings esp. when a byte of my number resulted in $< so binary is
definitely the way to go.

The issue now is that I'd like to have dynamic context retaining some of the
benefits of XML.  

I've done ncpdp transactions where header info is encoded <special header
character>A36<special header character>36 bytes of alpha header
information<special body segment character><field separator character>field
id<field separator character>data ....

Is this the best way to do mixed alpha and binary or can anyone suggest
better ways to pass context info, for example like in headers or to map XML
like structures to Binary or a way to detect and translate what is a string
and what is a number in a byteArray?

My goal here is to maximize storage and transfer speed, I learned my lesson
in my last system where we encoded UUID's as characters, and you wouldn't
think it but they used up a huge amount of room on Oracle, and consumed a
very large amount of network traffic.  

Thanks for your help!

Ron Teitelbaum
President / Principal Software Engineer
US Medical Record Specialists
[hidden email]  

Ron Teitelbaum wrote:
> Is this the best way to do mixed alpha and binary or can anyone suggest
> better ways to pass context info, for example like in headers or to map XML
> like structures to Binary or a way to detect and translate what is a string
> and what is a number in a byteArray?

ASN.1 with BER/PER/DER? While a full ASN.1 implementation for Squeak
would be nice ;-) , a custom codec that simply makes use of ASN.1 rules
will probably get the job done for you... and you get a nice
well-understood description of your data structure as documentation, as
well.

http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf
http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf
http://www.iana.org/assignments/enterprise-numbers

Tony,

Thanks for the links.  We are currently working on a full version of ASN.1
in the cryptography group
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography (I
know you are already a member, the link is a shameless plug for new members)

The version that Paul Davidowitz is working on is almost complete and we
could use some volunteers to help review and test the implementation once it
is completed.

I was trying to avoid unnecessary complication and definition transfer since
I'm moving data from squeak to squeak, I know I need ASN.1 for things like
X.12 where I'm going from squeak to the world.  Although it does seem silly
to throw yet another custom protocol, so I'll give it a try with Paul's
pre-Alpha code and see how far I get.

Thanks Tony!

Ron Teitelbaum

> I was trying to avoid unnecessary complication and definition
> transfer since
> I'm moving data from squeak to squeak, ...

If all you need is to move objects from image to another image, my
instincts would be the same as yours; TSTTCPW is to...  just use the
facilities needed to accomplish that.  Implementing some outside format
just to move data is going to require more implementation effort than
just doing it yourself.

The only reason I've ever been inclined leave object-land and use
committee-developed formats is to accommodate foreign system
requirements.  And, I might add, its never been a problem because
interoperability is relatively easy when you can source from pure
objects; compared to, say, trying to go from one standard format to
another standard format.

Case in point was a system I worked on where they used XML CLOBs to
represent a large portion of their domain model.  This freed them from
a lot of DBA tyranny but brought on parsing hell.  SAX parsers were
everywhere, with filters feeding other filters, and mysterious XSL bugs
(ever try debugging XSL?).  Half the code was just maanging the
difficult XML format.  Whew, talk about a nightmare.

 - Chris

Thanks Chris,

I think I'm going to do both but I agree with simple is better.  Paul and I
are going to work on his ASN.1 implementation since I really want to get it
completed for X.12 anyway (and I'll go back to Cincom once we release a
newly licensed squeak and evaluate their implementation and the possibility
of porting the code to squeak).  We decided in the Cryptography group that
ANS.1 needed to be done anyway so the effort is not wasted and the learning
experience is good too.  Still I agree with you after reading about the xml
and ASN.1 and looking at the translation code from xml to ASN.1 it's not
worth it for my squeak to squeak transfers.  Still having both as an option
is a good thing!  Just wait and I'll have Squeak objects stored in LDAP!

If anyone else would like to JOIN the cryptography group please let us know!

http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography .  

Ron Teitelbaum
Cryptography Team Leader