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

 

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of Chris Muller
> Sent: Wednesday, June 07, 2006 3:33 PM
> To: The general-purpose Squeak developers list
> Subject: RE: How safe is this?
> 
> > 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
>