> 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: [EMAIL PROTECTED] home: [EMAIL PROTECTED] _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
