Major patch

[ivan]

On Fri, Oct 06, 2000 at 05:10:09PM -0700, Jason Spence wrote:
> Hi -
> 
> It's Jason.  From Fry's Electronics?  

Hi!  Long time no talk.

> We've been doing some development on Freeside and have a major patch
> ready for your approval.  The patch adds:

Cool!  Some comments below:

>  Javascript to do input validation, client-side password generation,
>  username capitalization, etc. in CGI.pm

There should be a configuration option to toggle all javascript off/on
(defaulting to on is fine) as well as configurtaion options to turn off
anything that people might not want (for example, all installations might
not want username capitalization).

I'll probably outright reject client-side password generation, that sounds
like a bad idea.

>  A trouble ticket database with hooks for adding tickets in
>  cust_main.pm

See below for trouble ticket stuff.

>  A "users" table (which doesn't get it's hooks from secrets/mapsecrets
>  yet)

Yes, you could database the Apache auth and put everything in the
database.  For an application such as yours, with a large number of
employees, this is probably the way to go.  Apache::AuthDBI etc.  I can
provide some help on this.

>  Commissions report

Very interested.

>  We've been using a jailed perl, so we have a separate patch to go in
>  and change the shabang in every perl script to something like
>  #!/home/freeside/j/bin/perl 

Aren't you using mod_perl?!  The shebang line should be irrelevant on all
the htdocs/ stuff in that case. 

About the only thing here useful for integration into the base release is
maybe a patch to rewrite the shebang line in all the scripts at
compile-time or something.  Doesn't seem terribly important to me; no
worries if it isn't worth your time.

>  Rewired "shellmachine" which allows many shell machines and autocalc
>  of MD5 password hash for useradd -p

Hmm.  :/  I'd like to see this.

>  Patches to the RADIUS export script to make it work better with
>  cistron radiusd when there is no ACP stuff installed.  What is this
>  ACP stuff, anyway?  AIX Certified Professional?  Another Command
>  Processor?  The Bay Networks ACP radius-alike?  

The last.  Xircom's actually IIRC, they were swallowed by Bay.  Of
questionalbe usefullness, but it doesn't break anything, so no reason to
remove it.  Why is it causing you problems?

>  ... and some other stuff I can't remember.
> 
> How do you want to go about applying the patch?

In an ideal world, it would be against the current CVS, and you'd
either:

-feed it to me in small pieces, broken up logically
-check it into a branch in cvs and help merge it onto the trunk

>  You interested in any of this stuff?

Definately.

> I'd like to see it merged in so that we don't end up
> with an internal-only fork of Freeside.  I need to port the patch to
> 1.2.3; it's only valid against 1.2.2 right now.

It would be better if you could port it against current CVS.  A 1.2.4
release is kind of overdue.  :) 

> Internally, we've also been using perl reformatters to clean up your
> tabbing.

Notwithstanding any problems with my style (I'm sure there are), doesn't
this make it extrememly difficult for you to track my source, and
vice-versa?

>  A few people over here have pointed out the inconsistent
> tabbing in the code, which they say makes it very difficult to read.
> How do you feel about this?

*sigh*  I don't have much of an opinion, really.  I mean, I don't think
the indentation style is particulary difficult, but it's my code.  

I do want it be as clear as possible for other folks and am amenable to
patches that format all the code according to a common style.  I'd want to
keep this separate from any functionality patches as it is likely to take
longer, and I'd want to see at least a loosely-defined style guide that
doesn't conflict too much with perlstyle(1). 

> I'm personally don't care when people give me patches as long as they
> use my tabbing style,

I don't care too much one way or the other; I'd probably accept a patch
with a different "style" as long as it was clean code.  OTOH it's often
hard to differentiate signal (code changes) from noise (formatting
changes) if someone just reformats for the sake of reformating.

> but no one has
> been able to figure out what your tabbing style is; you seem to use
> many different ones.

I do?  It seems consistant to me... :(

>  It's tough to help emacs figure out what to do
> to the tab variables when it sees -*- febo-freeside -*-.

Eek!  You need to use a custom emacs mode?  The standard perl or cperl
modes don't work?  That does seem problematic.  :/

> The trouble ticket database adds a few tables to the database, and
> I'd like your help to create a cleaner API than the one that I've
> created so far.  I'd like all that stuff to be a subclass of
> Record.pm, to keep all the database accessing consistent.

The future direction for Freeside trouble ticketing is integration with
RT: <http://www.fsck.com/projects/rt/> - or with anything really, although
RT is the first target I'd like to make sure the interface/API is
well-docuemtned.

I'm amenable to including trouble ticketing stuff in the base Freeside
source in the short term; in the long term you should plan on moving to RT
or maintaining this ticketing system as a separate project (which would
interface with the same API as RT, above).  Does that makes sense?

WRT FS::Record usage, it was always intended as a generally-useful rather
than Freeside-specific database interface.  Feel free to use it as such; 
although the name will change when it becomes a CPAN module (Real Soon
Now), the functionality should be the same. 

> We've been using Text::Template to do a lot of CGI stuff lately,
> mainly because then we don't have to bug the programmers to change
> HTML.

You don't have to convince me.  I've been chewing on this problem for
quite some time.  I've rewritten pieces of Freeside in Embperl, Mason,
eperl, and with a custom Text::Template-based handler, looked at more
templating systems I know what to do with, etc.

For background, you should check out this message from Mark-Jason
Dominus, the author of Text::Template:

http://forum.swarthmore.edu/epigone/modperl/frahthonbror/19990525144012.8806.qmail@plover.com

For the template system for Freeside, I wanted to use of the of the `eval'
group, not the `little language' group.

Text::Template is unfortunately unsuitable because it's backwards: instead
of parsing text sections as embedded perl `print' statements, it parses
each perl section as a self-contained perl program.  What this means is
that you can't use loop constructs as part of the larger progarm, i.e.
(assuimng <% and %> for delimiters): 

	<% for $i ( @l ) { %>
	    HTML that goes with <% $i %>
	<% } %>

and you wind up jumping through hoops to do the equivlant.

Mason depends on mod_perl (no support for using it as plain CGIs), and
doesn't work with taint mode. 

eperl is not maintained very well and has idosyncratic parsing rules
(instead of always substitutiong like Text::Template, you are supposed to
print to STDOUT). 

The requirements I've been looking for are:
  -`eval', not `little language'
  - allows you to spread perl constructs over multiple sections
  - will work as a CGI as well as caching with mod_perl
  - stable and currently maintained, etc.

I do wish there had been a sucessor to Text::Template that wasn't
backwards.  In the absense of that or something else that fits the
requirements, I'm going to use a custom template syntax (probably
<% and %> delimiters) that runs through a preprocessor and then outputs
eperl or Mason syntax (and anything other suffiecent `eval' language that
comes along).

If you're ready to make this happen for Freeside now I can do most of the
wizardry to make all that go; unfortunately I don't have time right now to
do all the work of converting the web interface to templates. 

[ snipped example Text::Template code ]

[ snipped preaching-to-the-choir advanges of template systems ]

> We've also created a Freeside CSS file over here which we've been
> using for the trouble ticket pages, instead of having to do all the
> formatting ourselves.

Once the web interface stuff is properly templated, I'm pretty much going
to wash my hands of it.  If I could find an HTML/UI design person that
knows their stuff to take "ownership" of that, even better.  My HTML-fu is
years out of date.

-- 
meow
_ivan