Parser portability issues

[ljanyst]

Hello everyone,

Thanks for developing this new IMAP library and improving the bridge!

I have noticed that you generate ANTLR C++ parser to process the IMAP commands and this results in a need to pull some static libraries and do some heavy lifting to communicate between go and C++. I currently run the bridge on a bunch of architectures that you don't normally support. It's normally pretty easy with pure go, but quite a pain if you need to interface with C++.

ANTLR seems to be capable of generating go directly without having to go through C++: https://github.com/antlr/antlr4/blob/master/doc/go-target.md. Please consider using that instead. It should significantly simplify your integration and testing process too.

[jameshoulahan]

Hi @ljanyst, thanks for your interest in the library and in our products!

I definitely understand your concerns regarding portability and unnecessary complexity. Indeed, we used ANTLR's go target earlier in this project's history, and we already use it in another library used by bridge, see go-rfc5322, but we were forced to switch to C++ because the generated go code was horribly slow.

Longer term, we are interested in investigating better solutions to parsing the IMAP commands, but for now, we will stick with the current approach, as it is the simplest way to get a high quality parser for all of our officially supported architectures.

[ljanyst]

Thanks for taking a look!

[kortschak]

@jameshoulahan Did you take a look at using ragel for this?

[jameshoulahan]

@kortschak no I didn't, I wasn't aware of it at the time. What would be the benefits of using it?

[kortschak]

It's significantly simpler than antlr.

[LBeernaertProton]

To all those who are interested, work has begun on rewriting the C++ parser dependencies in pure Go.

[LBeernaertProton]

As of c8f22fc, Gluon no longer depends on C++ libraries. The issue is now considered resolved.