Death of irrtoolset?

[S.P.Zeidler]

Hi,

Thus wrote Jonathan Day (imipak at yahoo.com):

> > The code is unmaintainable.  Completely and utterly
> > unmaintainable.

s/Completely and utterly unmaintainable/a serious PITA to maintain/
IMO the licensing is the worse problem.

> (snip)
> 
> Ok, so maintaining the existing codebase is impossible. Where does that leave us?
> 
> Rewriting the entire toolset from scratch is going to be hard work and I sincerely doubt that there'd be a whole lot of funding for it. The "if it works, don't fix it" mindset is superbly honed in the minds of bursars and CFOs when it comes to asking for funds for such projects.
> 
> On the other hand, is there an actual need to replace the entire toolset in one go? So long as none of the applications is completely broken, it would seem to make sense to roll gradually from what's there now to irrtoolset-the-next-generation.

The actual front end code is not that terribly hairy (as far as the
backends let it). The problem is the libraries irrtoolset contains that
all apps use. They'd need a rewrite.

My own preference, btw, would be to have a core C or C++ tool that
replaces peval, but spits out something more suited for being fed into
other pieces of code (like XML), and replace everything else with
perl modules. This way one could continue using lex & yacc, which makes
catering to features of RPSL a lot easier, and if a rabid fan of, say, lua
wants stuff in their language they can reuse the hard part easily.

I'd like to be a more active contributor but all my 'copious' free time
currently gets eaten otherwise, so if someone feels like charging ahead,
don't wait for me :-7

regards,
	spz
-- 
spz at serpens.de (S.P.Zeidler)