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

[Erich Ocean]

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
>>
>>
>>
>>
>>>
>>
>
> >