Welcome to the ICOD Framework project on SourceForge.net. The ICOD Framework is a tool library which extends the CLF for greater functionality. The projects are all rooted on the Icod assembly, so at a minimum one must download and install this assembly to use any of the others. The project consists of several assemblies (not all of which have been
Everything within the ICOD Framework is governed by the GNU LGPL. The decision for LGPL over GPL was based on the definitions of the two licenses; the intended purposes, freedoms, and restrictions of the two. The decision of LGPL over GPL is sound and is not subject to debate.
This has yet to fully complete. Some assemblies have not yet been upgraded, and it is expected some of those assemblies may merge.
Icod.Security.Cryptography.Tls and Icod.IO.Compression.Deflate and Icod.IO.Compression.Gzip were all dropped thanks to the timely inclusion of these functionalities within the .NET2 framework.
Planned for immediate action is adoption of the v3 LGPL.
This will require some changes to the root Icod assembly,
and the addition of the two COPYING files to all projects as content/do not compile/include always
.
A class hierarchy of license versions must be authored (with v3 the default) such that authors can specific which revision they are referencing,
with v3 the default in cases of [Icod.LgplLicense] definition.
Following this step, the Icod.Net.* namespace will be revised.
A great deal of work is required for this.
Regular Expressions will be seperated from the source code, pre-comiled, and included into a resource library.
This will require authoring a special RegEx compilation tool to maximize use of the \k
switch, rather than including definitions bodily.
It is expected this alone will shrink the .data and .text sections of the resultant library by over 50% of present size.
This should also speed up the already lightning-quick performance.
The next step is upgrading the Icod.Net.Text assembly to take advantage of .NET2 Generics.
Once that is completed the various application protocol wrapper clients will be considered for merging into a common assembly, but retaining their distinct namespace.
It is possible the various assemblies will remain seperate and distinct, depending on how large the resulting library becomes.
They provide a means to kill several birds with one stone.
First, their inclusion is semantically equal to including the boiler-plate text in the source file itself.
Secondly, they include the licensure in the generate BINARIES.
This ensures people are getting what they expect;
just because a bunch of .c files in a package make a certain reference does not necessarily mean the included binary does.
Only if one compiles said sources himself can one have any reasonable expectation the intended binary is governed by any restrictions mentioned in said sources.
By including a custom attribute on all classess and assemblies, one instantly knows the licensing restrictions about those bindaries.
If the GplLicenseAttribute or LgplLicenseAttribute is missing from any binaries, then those binaries are clearly not governed by either license.
This may or may not be a Good Thing, as you decide between Good and Bad.
The decision for binary tagging was selected because the average
use is where a programmer doesn't bother to recompile (they often don't even bother downloading the sources!).
Any decompilation, reflection probing, etc, etc, will clearly and unambiguously indicate the license (or lack of license) governing ICOD Framework libraries.
Of immediate concern is creating a custom target file, and custom VS project type for help file compilation. Both v2 (Help Studio Lite) and v1 (Help Workshop) types must be supported. Currently there is some working code using Sandcastle, and this is the technology which will be used.
One goal is to offer reliable, robust, RFC-compliant (not UNIX-brain-damaged) services which take advantage of the NT subsystem, but also incorporate 3rd-party semantics.
These would include an NNTPd, FTPd, SMTPd, POP3d, and IMAP4d, all which support intrinsic NT security as well as .htaccess, and the dbaccess/forms access a la ASP.NET.
While I personally do not see a need for models like .htaccess
(and I do have much experience in the subscription-based content
business from a stint in the pornography business),
there remains many who feel such a mechanism is necessary.
Likewise, others would prefer to authenticate via their ASP.NET role/member database for all network services (such as NNTP for forums[sic]
or FTP for file-sharing).
Such mechanisms would be quite powerful to the community at large, and their benefit should be self-evident.
These ideas spring from my love for NT, combined with the fact that NT no longer ships with a working NNTPd, and the last NNTPd was rather limited (could not join the usenet).
I was never happy with the NNTPd's operations, but I was in love with the MMC.
My goals for the next few months are to author a decent NNTPd which takes advantage of the NT security model,
extends the authentication base to include at a minimum ASP.NET role/member database support as well as an .htaccess file,
is manageable via an MMC-snapin and .cpl,
supports standard push/pull replication in usenet,
and supports TLS1.1.
.NET's intrinsic inclusion of the TLS protocol was quite timely and fortuitous for me.
The ICOD Framework was originally authored in nothing more than pico on an old laptop running an incomplete build of Mono 0.8. While I do not instantly prefer Visual Studio over notepad and pico, VS has aided the development of the ICOD Framework substantially. Since I had some serious problems using the .NET2 enabled Mono on that laptop, switching development over to the WinXP/VS2K5 laptop was necessary for migration to the .NET2 technologies. This also gave me all the benefits of working within an IDE rather than a simple editor. On the whole I'm quite happy with the present situation, but a substantial portion of my work still involves typing code by hand in pico and notepad; a mode in which I am quite comfortable operating.