Re: Special Interest Groups - HTTP/CGI and SMTP/MIME

On Tue, 17 Mar 2009 00:32:23 -0400
"Eric S. Johansson" <[email protected]> wrote:

> Chris Babcock wrote:
> > What I'm really panting for is a socket interface. When netcat is in
> > listening mode, it doesn't close stdout until the client closes the
> > socket. That makes the keep flag useless for running a server on
> > just about any protocol. I want to set up something co-routine-like
> > that blocks execution of the crm script while waiting for a network
> > connection then spawns a handler thread to deal with the connection
> > while the main program goes back to waiting for a new connection.
> 
> for me, I suspect there is a minor difference between a demon and
> forking a process.  Reason being that I'm switching css and
> configuration files for every user.  It would be interesting to see
> if caching helps at different ratios between size of cache and number
> of users.

I said "thread" because I'm looking at Python code and looking to
emulate that behavior.

I'd prefer threading if it was available so that I wouldn't have to
worry about process count. That's not the issue for server apps, because
I'm not going to run 50+ concurrent connections on a home-built server
app... at least not deliberately. In a mailing list app, however, the
SMTP client could easily hit local process limits.

> > Of course one of the reasons that I like CRM as a scripting
> > language is that it loads faster than perl:
> 
> well, since I consider Perl only slightly more understandable than
> crm, I'm not sure this comparison has a high value.  :-) never forget
> that I'm the person that coined the phrase "crm is teco on acid".
> I'm sure Bill won't.  :-) although, that saying might make an
> interesting T-shirt if you had the right background (still life of
> sugar cubes and blotter paper?).

Those quotes certainly add some cachet to the CRM scripting language.
The language has niche appeal. The quotes in the docs with phrases like
"on acid" and "bitten by a radioactive spider" and the stoneresque
coloquiallism in the error messages create a brand image of coolness.
That's not a marketing approach for dominating any market segment, but
it's solid guerilla marketing tactics. If there's anything to learn
about marketing from Python, it's that funny and irreverent are great
for building a loyal user base while working on the fundamentals. Doctor
Strangelove may not have as broad a mass appeal or as deep a cult
following as Monty Python or even Rocky Horror, but CRM has other
compensations as a brand... like actually bearing some relation to the
product.

> Seriously, I do think that Lib CRM biggest value will come from
> including it in different languages such as Python, Lua, Ruby etc.
> I've tried a bunch of analysis tools like CRM 114 and quite frankly
> it's the best.

I won't dispute the value of CRM libraries in other scripting languages,
mostly because of the relative installed base. I do think that the
'native' interface will be easier for experimenting with classifier
choices and training methods than imports into other interpreted
languages - at least initially. It's also my suspicion that, for
prototyping, CRM scripts will be more likely to end up as compiled code
because it maps more obviously to the underlying C code than Python and
other 'prototyping' languages.

> > Some flavor of scoping or notion of name spaces will have to happen
> > before it's feasible to develop library code... and candidly, that's
> > what I spend most of my time doing. I've got a dirt simple SMTP
> > client, some basic CGI stuff and an HTML template driver. It's
> > surprisingly few LOCs, but it's enough that I've put off upgrading
> > to BlameBarack. 
> 
> I can understand why you want to implement these protocols in crm.
> It's great if it does something  (intellectually, spiritually, etc.)
> for you.  I'm using pre-existing libraries in what I consider to be
> more comprehensible languages. That's what floats my boat.  :-)

I like CRM. Really. It's got its warts, sure enough, but it is something
different than Scripting Language 'P'. For the most part that's a good
thing. Take my HTML template driver, for example:

input (:template:) [:*:master:]
input (:content:) [:*:_env_PATH_TRANSLATED:]
# This could get ugly if you're not careful.
eval (:_dw:) /:+:cgi_headers::+:template:/
accept

What this does, for a master template and other variables defined in
the script (can be hard coded, supplied by a lookup or defined by CGI
input), is insert the HTML document or template supplied by the CGI
environment into the master template and expand the variables contained
in the combined document. 

There's no Mako v. Genshi here. The four lines of code to do this
aren't library calls, they actually do the work. The variables are
embedded in the HTML, making the templates editable in WYSIAYG editors
just like Genshi/Kidd templates, but there's no parsing involved so
they execute very quickly. The content doesn't even have to be
HTML/XML. With :cgi_headers: set to something like "content-type:
:*:mime_type:\n\n" the mime-type might be determined by a lookup or
some MIME magic in the script. This opens up a whole world of actually
being able to honor the preferences that the user's browser submits via
the HTTP Accept header.

It's not perfect. Bad things happen if you have ":*:content:" in
your :content:, for example. It's still pretty sweet. I play a few
tricks with the file system and the Apache configuration so that 
/path/file.html serves file.html wrapped in the master template, but 
/content/path/file.html serves it bare. That way there's a single point
of maintenance for each component on the page and the content can be
served either as a whole page (straight CGI) or by itself (as part of
some AJAX hanky-panky).

Sure, there's something about reading RFCs that's quite a bit like
walking on live coals, but the point of the exercise is pragmatic rather
than spiritual. I took it up because I have to work with data in
arbitrary formats, usually in streams, but it turns out that I'm able to
do some neat things that aren't necesarily made trivial by existing
library code in other languages. I can't sat that the ROI is there yet,
but as long as the language is support I'm sure it will be.

Chris

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

_______________________________________________
Crm114-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crm114-general

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQEcBAEBAgAGBQJJv9qNAAoJEASgqNsqZfCHxkkH/jVjPM+GpjyWZaM1D61qAOZk
IHX5KtM9MOLtG4iZ2ZutSKWHXnjHp5wn25QwUxXXPV41f4zH0j6Sm13JWeJwigGK
k6genWDOsvLbrtq8DdlHNzNDTsxhV4mmbZmIevluSJ/9QuuYleRQqTq1XzCE7IEQ
mAFy39cJP3WKH8SS41C/wgnzW8rZ3/wz9Cp2qRpXMiKBx4JwlGLCwoysOWVpTQmP
DreYPmmqQkAIdxHY6eWIvROgNhTXWiwtvBTN0wqSxpM2WSxaosK3anr6/sGR0YOB
3dG5YEd2GZFI4B08rTW8JJSA/ps+yFn6ZKSfp7NRcOacPMHaasHFqKNM2NQSH+E=
=Dj5t
-----END PGP SIGNATURE-----