Well, go ahead, but it still seems brain-dead to be reimplmenting something that's already done. The space argument is fatuous - have you ever looked at the memory profile of a running mono app?
Isn't it better to get this stuff running in the most portable way without duplicating whole chunks of effort just to satisfy some far-off 1% scenario? Piers. -----Original Message----- From: Sebastien Pouliot [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:31 PM To: mono-list Cc: Paolo Molaro; Piers Haken Subject: Re: [Mono-list] Crypto Unit tests on linux Thanks for all three options. > 1) write a small xml parser that handles just the stuff you need in > corlib > 2) (better, IMHO) write an internalcall that uses the GMarkup parser > in glib and fills in the RSA and DSA structures. > > 3) use: Assembly.Load, Activator.CreateInstance & MethodInfo.Invoke I would find the reflection stuff much easier but Paolo has a good point. I've participated in the design and implementation of a hardware token which included crypto, smart cards and biometry (and I even looked at how we could get a JVM into that box). I know that I would have hated any design that didn't minimize dependencies as much as possible (as such design are often very limited on memory space). However I would like very much, if possible, that the crypto classes to be implemented using 100% managed code and I know that some other classes are gonna require a lightweigth XML parser (probably CryptoConfig but I've not finished looking at the System.Configuration classes). So I will put the small parser on my todo list (unless someone else is interested :-) and comment the current "bad" code so the tests (and classes) can be compiled back into mono. Thanks, Sebastien Pouliot Security Architect, Motus Technologies, http://www.motus.com/ work: [EMAIL PROTECTED] home: [EMAIL PROTECTED] _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
