From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,2b909902584f450a X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!e39g2000hsf.googlegroups.com!not-for-mail From: google1@hafdconsulting.com Newsgroups: comp.lang.ada Subject: Re: ANN: Basil -- Internet Message (email) and MIME library for Ada v 1.0 Date: Tue, 22 Jul 2008 12:43:57 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <3d42731b-4669-414e-87cc-454260ef62ec@d1g2000hsg.googlegroups.com> <1ff77708-02c3-4552-a8a0-128a7fc34581@27g2000hsf.googlegroups.com> <877ibdhm4g.fsf@ludovic-brenta.org> NNTP-Posting-Host: 68.20.35.30 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1216755838 18467 127.0.0.1 (22 Jul 2008 19:43:58 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 22 Jul 2008 19:43:58 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: e39g2000hsf.googlegroups.com; posting-host=68.20.35.30; posting-account=OhyMIwoAAABpudocR3HA8t2ohhQMuzpv User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux sparc64; en-US; rv:1.8.1.8) Gecko/20071004 Iceweasel/2.0.0.8 (Debian-2.0.0.8-1),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:6981 Date: 2008-07-22T12:43:57-07:00 List-Id: On Jul 22, 12:19 pm, Ludovic Brenta wrote: > If you're planning to use AWS's SMTP client code, it looks like you're > going to need this glue for your mailing list server anyway. SMTP won't be needed for the mailing list. People want mailing list servers that are integrated with their existing MTA systems, they don't want stand-alone systems. Mailman, one should note, provides interfaces with all the popular Unix MTAs and it's quite a bit of their code base, they did not, last I looked, provide an integrated MTA. There *might* be some advantage to providing an integrated MTA particularly if AWS makes that very easy to do, but it would not be a very popular feature of the system at all. I am considering using AWS for the web interface portion, but then again you have the same integration problem. People want their web applications to run behind the web server *they* choose (or at least Apache) they don't want a stand-alone system. There are some people around working on web interface systems for Ada. When I get to that phase I'll look at them, and also look into the possibility of making an AWS-based system integrate with Apache. But integration with existing web servers is a killer feature for any interface I choose. > The reason I wasn asking is not because I was interested in using your > library; only because I think it is nice in general to consolidate > small but related libraries into larger ones, I take exception to your belief that Basil is a "small" library: [murat:~/projects/basil-1.0]$ sloccount . [...] Totals grouped by language (dominant language first): ada: 10823 (98.29%) python: 146 (1.33%) sh: 42 (0.38%) Total Physical Source Lines of Code (SLOC) = 11,011 Development Effort Estimate, Person-Years (Person-Months) = 2.48 (29.79) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 0.76 (9.08) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 3.28 Total Estimated Cost to Develop = $ 335,397 (average salary = $56,286/year, overhead = 2.40). SLOCCount, Copyright (C) 2001-2004 David A. Wheeler > or at least host them in > common places, so that users can find them more easily. Well, I have a 'selfish asshole' motive for working on these projects and provide them as free software, that is to promote my business. And that is why they'll be hosted on my professional website. But I think inside a week if you put "MIME" and "Ada" into google, that page will be the top hit, with this message and other forms of publicity. Mr. Hermann has already informed me that he has added it to his list of Ada resources, for instance. And of course, the Debian developers around here could certainly help make it easier for people to find and use it. :) > Another > benefit is to avoid inconsistencies and incompatilibities between > libraries, so that a single program can use several libraries > simultaneously. And, of course, to reduce duplication of work. > Speaking of which, is there a good reason why Basil needs its own > "header objects" different from AWS's "header objects"? Compared to *everthing else* in RFC 2822 and MIME, unstructured headers are a very simple concept. They're just a key string, a colon, and a value string, terminated by a non-folded CRLF sequence. RFC 2822 specifies the CRLF but to make Basil more robust, I made it also handle lone CR or LFs. So that was no great part of the library but it is a core part. To use AWS I would have had to integrate every layer with that system, making it a hard-dependency for building or using Basil, just so it could do the light lifting beneath all of Basil's heavy lifting. Also, my header lists *are* integrated into the Doubly_Linked_List containers. My Headers.Lists.List object is a subtype of the DLL, so any operation you could perform on a DLL you can perform on my lists (except sorting isn't supported because of that interior generic). I also provide a custom equality function that considers things equal if their case insensitive keys are equal (per RFC 2822), this allows you do do something like use the Find operation to iterate over all headers with the same key. I tried to make this library integrate very well with the Ada language, to leverage the power of the features that it has and provide an interface that mimics the behavior of relevant core interfaces that are already well-understood. I didn't see much use in integrating with vaguely related external third-party libraries, making the system more difficult to install and use. But anyway, that's why I made the technical decisions I made. Of course writing software is the process of choosing between many different choices which all have their merits and downsides. Maybe you're right and I should have done this completely differently, there's not really any way to know for sure. I would like to thank you for your incredibly fast response to the bug I filed against gnatpp. Thanks, -- Jordan Bettis