[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SEUL: Re: Working

In message <Pine.GSO.3.96.980911143043.22576A-100000@homebase>, mdunnett@citilink.com writes:
>I agree (about ActiveState and their license, that is). 
>I have been surfing to see what else is out there. There are a couple of
>HTML parsers/embedders out there too (a couple in CPAN). Just checking to
>see if the wheel is out there.

Actually, thanks for reminding me. I had been pondering earlier
replacing my hacked-together html parser with something more elegant
that cpan had. In particular, I think that a new Parse_Params() might
be in order, since mine probably doesn't conform to html spec. (In
particular, I think we decided that we shouldn't handle parameters that
didn't have '='. The solution for situations like that is to not use
Parse_Params() and just parse things yourself, but to non-programmers
that doesn't sound like much of a solution at all.)

I'm confident that are some situations that would break my current
html parser, and besides that there are efficiency issues (I hope
that whoever wrote the cpan one put more energy into optimization
than I did).

Also, one other difference between the old sdoc and the new sdoc, that
I might not have explicitly described: in the old sdoc, the scripts
themselves are loaded into a variable, and when the handler is called,
the variable is 'eval'ed in the appropriate scope.

It would be really keen to set up the packaging/moduling system so that
instead of having Register_Handler() read the script into the variable,
it would create a method (SDOC::Handlers::foo) that could be called like
a normal subroutine. This would speed up handler spawning tremendously,
since each handler would not have to be recompiled each time.

This might be very tricky to implement though, if we're also wanting to
retain the "handler stack" idea. Basically we'd want to overload function
calls: the handler is compiled when it is Register()'d, and then pointers
can be thrown around as appropriate. This gets very complex very quickly,