[Mono-list] Crypto Unit tests on linux

[Sergey Chaban]

> For example having 100% managed cryptographic classes would allow (without
> too much pain) running cryptographic applications with the .NET Compact
> Framework (which doesn't have the System.Security.Cryptography namespace
> included in mscorlib.dll). 

FWIW, we have simple lightweight XML parser available here:
http://mono.eurosoft.od.ua/files/miniparser.tar.gz
It can be easily embedded into corlib dll.
It works with Mono and it works fine with WinCE/CF (tested with PocketPC2002, HPC2k & CE.NET devices)
When compiled it's about 10k of binary code. Parser uses event-based push model with very simple interface.
Main limitation: it can't handle mixed contents (shouldn't be a problem for config-file parsing).
License is Mono-compatible (see code for details)


Sergey


----- Original Message ----- 
From: "Sebastien Pouliot" <spouliot@videotron.ca>
To: "Piers Haken" <piersh@friskit.com>; "mono-list" <mono-list@ximian.com>
Sent: Thursday, October 17, 2002 6:01 AM
Subject: Re: [Mono-list] Crypto Unit tests on linux


> > 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?
> 
> No. But I see mono and the class library as two separate entity (which seems
> normal as they are licensed differently).
> For example having 100% managed cryptographic classes would allow (without
> too much pain) running cryptographic applications with the .NET Compact
> Framework (which doesn't have the System.Security.Cryptography namespace
> included in mscorlib.dll). See
> http://www.gotdotnet.com/team/netcf/ApiDocumentation.aspx for what
> namespaces/classes are present in the Compact Framework.
> 
> Yet in this case I confess that both using a independant parser or
> reflection into System.Xml would yield the same results (and invoking
> unmanaged code in the mono runtime wouldn't). However this may not be the
> always the case (perhaps customized PocketPC or something totally new).
> 
> > 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?
> 
> I agree this isn't a high priority (has we don't have any asymmetric crypto
> yet so the abstract class are useless now) but respectfully disagree on the
> % ;-)
> 
> Sebastien Pouliot
> Security Architect, Motus Technologies, http://www.motus.com/
> work: spouliot@motus.com
> home: spouliot@videotron.ca
>