[ragel-users] Re: Any suggestions on implementing SMTP protocol inRagel?

[Ross Thomas]

Hi Erich,

I had not come across Harel's work before (believe it or not) so I read the
paper containing the "spec" you mentioned. It was, needless to say,
extremely interesting, and very relevant for the systems I design at work
(which, I have only recently come to realize, are soft real-time systems).
Having poked around in Ragel a little more I see that you are of course
right when you say that it should complement rather than replace a
hand-coded statechart.

Do you know of any examples of statecharts describing a protocol handler, or
any good resources around statechart diagrams in general?

-Ross


On Tue, May 13, 2008 at 6:43 AM, Erich Ocean <er... at atlasocean.com> wrote:

>
> Ross,
>
> Statecharts are trivial to code by hand, using case and switch
> statements, and result in roughly the same amount of code as a
> straight Ragel implementation would. In addition, the hand-coded
> variants are more flexible, since you can implement the full "spec" as
> designed by Harel. You can also easily embed Ragel regex-style
> machines in the various states as needed when you hand code, and
> Adrian's code generation approach makes that particularly easy.
>
> Bottom-line: hand-code statecharts. The hard part is creating the
> statecharts themselves (I use OmniGraffle), not coding them up.
>
> That said, I wouldn't create a protocol handler without them. They are
> extraordinarily efficient, **easy** to debug, and quick to modify. I
> create and modify statechart-based code daily at my day job, and use
> statecharts on my own projects.
>
> Zed Shaw has done some work with Ragel and statecharts if you still
> want to go down that path:
>
>        http://www.zedshaw.com/tips/ragel_state_charts.html
>
> Best, Erich
>
> On May 12, 2008, at 9:46 PM, Ross Thomas wrote:
>
> >
> > It seems to me that the approach I describe cannot work as I wanted it
> > to, because the regexps matching the commands are duplicated for each
> > state, only with a different target state. For example:
> >
> > main := (
> >    start: (
> >        1 -> a
> >    ),
> >    a: (
> >        1 -> b
> >    ),
> >    ...
> > );
> >
> > Given the input [1, 1] the machine will end up in state "a", not state
> > "final" as I thought. Which makes sense now I think about it.
> >
> > Back to the drawing board... :)
> >
> > -Ross
> >
> >
> > On Mon, May 12, 2008 at 6:15 PM, Adrian Thurston <thurs... at cs.queensu.ca
> > > wrote:
> >> Hi Ross,
> >>
> >> To be honest I don't have much experience with this approach.
> >> Statecharts were originally made for small low-level machines that
> >> are awkward to do with regular expressions. But they turned out to
> >> be more useful. The only issue I can think of is dealing with
> >> whitespace ... but I don't know SMTP well enough to say for sure.
> >> Let us know if if you pursue it and it works out :)
> >>
> >> Adrian
> >> -----Original Message-----
> >> From: "Ross Thomas" <halfacan... at gmail.com>
> >>
> >> Date: Mon, 12 May 2008 15:17:27
> >> To:ragel-users <ragel-users at googlegroups.com>
> >> Subject: [ragel-users] Re: Any suggestions on implementing SMTP
> >> protocol in
> >> Ragel?
> >>
> >>
> >>
> >> To reduce the scope of my question a little, here is the general
> >> structure I have so far:
> >>
> >>   main := (
> >>       start: (
> >>           helo @copy_helo @resp_250 -> wait_mail |
> >>           mail @resp_503 -> start |
> >>           vrfy @resp_503 -> start |
> >>           ...
> >>       wait_mail: (
> >>           helo @resp_250 -> wait_mail |
> >>           mail @copy_mail @resp_250 -> wait_rcpt |
> >>           vrfy @resp_252 -> wait_mail |
> >>           ...
> >>   );
> >>
> >> Each "helo", "mail", "vrfy" etc. machine corresponds to the SMTP
> >> command of the same name. They are defined as:
> >>
> >>   helo = (("HELO"i | "EHLO"i) " "       %sarg graph+ %earg     eol);
> >>   mail = ( "MAIL"i            " FROM:<" %sarg path*  %earg ">" eol);
> >>   vrfy = ( "VRFY"i            " "       %sarg graph+ %earg     eol);
> >>   ...
> >>
> >> So the idea is that the top-level state chart handles logical flow
> >> and
> >> knows which commands are valid in which states, and calls the
> >> appropriate actions. The tokenizing is done "inline", as it were.
> >>
> >> Does this strike anyone as a particularly foolish approach? Is
> >> there a
> >> better way?
> >>
> >> -Ross
> >>
> >>
> >> On Sun, May 11, 2008 at 11:57 AM, Ross Thomas
> >> <halfacan... at gmail.com> wrote:
> >>>
> >>> While hacking up a parser for SMTP (in an unprecedentedly small
> >>> amount
> >>> of time, naturally :)) it occurred to me that given Ragel's
> >>> ability to
> >>> mix regular expressions with state charts I could make the same
> >>> machine double-up as an SMTP protocol handler too. At least, I
> >>> think I
> >>> could. Because a significant portion of my work involves the client/
> >>> server model this is an aspect of Ragel I'd very much like to
> >>> explore
> >>> in more detail...
> >>>
> >>> I've browsed around on the list and read Zed's post on state charts
> >>> but still don't have a totally clear idea on how this might be
> >>> implemented. Can anyone out there with more Ragel experience point
> >>> me
> >>> in the right direction?
> >>>
> >>> -Ross
> >>
> >>
> >>
> >>
> >>>
> >>
> >
> > >
>
>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.colm.net/pipermail/ragel-users/attachments/20080513/da09cb2f/attachment-0001.html>