[Q] using SmaCC

Hi,

I've been think about using SmaCC to create a MIME parser and would just
  like to know whether or not that would be overkilled or actually sensible.

I was also thinking about using it for parsing incoming traffic on an
IMAP, POP3 connection.
Is that a suitable use of SmaCC?

Günther

I use ANPOP POP3 from AdminSystem:
http://www.emailarchitect.net/webapp/popcom/
A full set of pop3, mime, s/mime, ssl rfc's

Dimitry,

thanks.

Fact is, VW, for example, already has excellent code for MIME parsing,
POP3, IMAP, you name it.

It is a bit tricky trying to snitch it and put it into Dolphin without
something like STS (Source tracking System).

I mean to say that I already have a fall back solution for creating an
Email client.

My question is rather if an experienced Smalltalker would consider
employing SmaCC for parsing socket read data into a protocol, such as
IMAP, POP3, or into a Mail Message (MIME), or if he'd consider it overkill.

BTW Bill (Schwab), I hope you read this, cause I know you've been using
SmaCC already to parse C code. How did that go?
Would it be possible, for instance, to create a generator where you can
type in C code and have it translate into Smalltalk?


Günther

Günther,

> My question is rather if an experienced Smalltalker would consider
> employing SmaCC for parsing socket read data into a protocol, such as
> IMAP, POP3, or into a Mail Message (MIME), or if he'd consider it overkill.

I suspect that would depend on the complexity of the protocol, and on
whether one wants to debug Smalltalk code or grammar specifications.
Not being hyper-fluent (to say the least<g>) with the latter, I tend to
favor dedicated parsers.


> BTW Bill (Schwab), I hope you read this, cause I know you've been using
> SmaCC already to parse C code. How did that go?

Reasonably well, but it started to look as though my particular goals
would be better served (for now) by a home-grown stateful hack.  I
expect that to change in the future when Refactory has a full C
preprocessor and the parser automatically produces a parse tree.  For
now, I would find myself struggling with relatively unfamiliar details
of scanners and parsers only to be left with significant work to convert
the output into something useful.

At present, my hacked parser is handling more than necessary for my
shorter term goals.


> Would it be possible, for instance, to create a generator where you can
> type in C code and have it translate into Smalltalk?

Very likely.  Of course, you would end up with translated C vs. good
Smalltalk code.  There is an excellent HTTP client for Dolphin; IIRC
it's Steve Waring's work.  Squeak also contains code for many common
protocols.  In fact, I have a port of at least part of Squeak's MIME
code.  If I have not made it available on my web site, I will be happy
to do so.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

Bill Schwab wrote:

> I suspect that would depend on the complexity of the protocol, and on
> whether one wants to debug Smalltalk code or grammar specifications. Not
> being hyper-fluent (to say the least<g>) with the latter, I tend to
> favor dedicated parsers.

Well the whole subject is rather knew to me, but I have a feeling, that
if don't check SmaCC out I will miss a lot.


>
>> BTW Bill (Schwab), I hope you read this, cause I know you've been
>> using SmaCC already to parse C code. How did that go?
>
>
> Reasonably well, but it started to look as though my particular goals
> would be better served (for now) by a home-grown stateful hack.  I
> expect that to change in the future when Refactory has a full C
> preprocessor and the parser automatically produces a parse tree.

Do you have any indication that they are planning to do so?

Squeak also contains code for many common
> protocols.  In fact, I have a port of at least part of Squeak's MIME
> code.  If I have not made it available on my web site, I will be happy
> to do so.
>

That would be nice, thanks!
I don't mean to bad mouth the port, but I've had a look at some of the
code in Squeak, and some of it occurred to be not exactly .... /divine/.

Günther

Günther,

> Well the whole subject is rather knew to me, but I have a feeling, that
> if don't check SmaCC out I will miss a lot.

Getting familar with a good parser/scanner generator is a Good Thing to do.
Without such a thing in your toolkit you will, indeed, miss out a lot.  (And
also spend a lot of time implementing third-rate solutions by hand when you
could get a first-rate solution for less effort.)

But I don't think that SmaCC (or any other parser generator) is really suitable
for email protocols.

For MIME, as I understand it[*], all you are doing is taking a bunch of data,
splitting it up into lines, and then further splitting it up by looking for
lines that mark sub-message boundaries.   For POP3, the protocol is /designed/
to be so simple that it can be implemented correctly in C (;-).  I think that
you /might/ be able to handle it in SmaCC, but you'd be going against the
grain, and it would be harder than just sending and receiving commands.

([*] I've never written a MIME decoder, so I may be missing something.)

One related area where it may well be worth using more advanced tools (I intend
to try this myself, but haven't got around to it yet) is parsing the more
complicated email headers.  Not splitting out the headers themselves (that's
easy), but parsing the contents of, for instance, the From: header value.
Their syntax is pretty complicated (too complicated to handle with just regular
expressions, for instance).


> I don't mean to bad mouth the port, but I've had a look at some of the
> code in Squeak, and some of it occurred to be not exactly .... /divine/.

;-)

I haven't been delirious about a lot of the Squeak code I've looked at either
(though I /haven't/ looked at the POP3/SMTP/MIME stuff).  Another reason to
want to write your own version is that, although these protocols and formats
are pretty simple (they date to the time when the internet programmers still
had some sense of good design), they are not /so/ simple that you can really
understand what they do without digging into the details.  And (IMO) a very
good way of getting into the details is to turn it into code.  And once you've
done that, why not /use/ that code... ?

    -- chris

Chris,

thanks.

I'm just looking at the MIME stuff in VW, and the first impression is,
that it is as proficient as I have expected from code in VW.

I would have an easier time analyzing and understanding this code if I
could simply run it in Dolphin, but importing it is quite tricky (I hope
I'll be able to afford a STS license soon).

Günther