SG User Interface

Discussion re sg development. You don't have to be a developer.

SG User Interface

Postby Guest » Fri Aug 29, 2003 1:39 pm

By: maratheamit ( Amit Marathe )
SG User Interface
2002-12-11 07:11
Josh, could you also check in the html/perl files
needed to run SG? They can reside in CVS in their own directory (called web-interface or something similar) within the spamgourmet module.


By: maratheamit ( Amit Marathe )
RE: SG User Interface
2002-12-11 07:48
I currently have access to a hosting account where I want to try installing SG to get a perspective on how easy/difficult the service is to setup. If I am successful, I would also like to write the how-to documentation for that task.

-- Amit

By: jqh1 ( Josiah Hamilton )
RE: SG User Interface
2002-12-11 08:54
I'm creating a shell account for us to use as well. I'll post the web modules.

A little more on that - for long term positioning, how does this sound?

a) the forwarder itself, either as a standalone daemon or as a plugin (separate process or not)

b) user config via:
a) user directory config files
b) some sort of standardized http/xml interface, web services would be good - we may also be able to implement clustering at this layer

c) web modules for different environments. A PHP-Nuke or Post-Nuke module would be great, and there could also be a JSP/Servlet version, as well as the current perl (hopefully mod-perl/apache registry compliant, but now running as cgi) module.

The current web stuff uses something of a MVC pattern, but lacks the middle tier (b) above.

By: syskoll ( Fred )
RE: SG User Interface
2002-12-11 10:09

Regarding "user config files", does that mean you plan to move the web interface configuration from the database to a file in the user directory?

c) Regarding rewriting in Java as a servlet, we'll face the problem of pattern matching under Java. This requires the java.util.regex package of Java 1.4 with is bleeding edge right now. Feasable, but we should wait until 1.4 is widely spread.


By: jqh1 ( Josiah Hamilton )
RE: SG User Interface
2002-12-11 10:33

I'm thinking that the mail filter/forwarder part should probably always be perl and/or c.

The middle tier web-services portion could be anything, but I'm a big mod-perl/apache registry fan (and such code can be written to use CGI as a lower performance, but nearly always deployable alternative)

The web UI modules could then be in multiple environments, since they'll just hit the middle tier and provide UI functionality. Hopefully, it'll be fairly trivial to create new web module if the middle tier is well put together.

BTW, this represents a significant amount of work. I'm just throwing it out for discussion. When I think about sg deployment, I'm kind of coalescing around these usage scenarios:

0) the single user, who has a unix account, but maybe no db - think of a non-root spamassassin installation

1) the bare-bones multi-user deployer (like now), using just a standard issue web hosting account

2) the ISP, who already runs a mail server and wants to add some value

3) the "web community" administrator who wants to provide the service to the various community members using an available hostname,

4) etc.? I'm having a hard time visualizing corporate admins, but who knows

In scenario 3, picture someone who runs a portal / blog of some sort using one of the available CMS packages, eg, PHPNuke. If that person could run the install of the mail handler/middle tier in one effort, then install a Nuke module for the UI in a second (hopefully minimal) effort, I'm thinking we'd be in good shape. For an Epicentric deployment, the mail-handler/middle tier install would be exactly the same, but the web module would be jsp/servlet.

The bit about using config files for the UI I suppose anticipates scenario 0. It might be best to deprioritize this for now, since it may complicate development without adding sufficient value.

This discussion exposes an inconsistency in the current sg release strategy - I provided the mail handler, but haven't provided a UI. What's kept me from doing it is that the current web code, while fairly well designed (IMO :)) has what I'd say is an unacceptable level of coupling to what's described in scenario 1, and I didn't want to wind up supporting it as folks tried to use it in other scenarios.

Return to Developers

Who is online

Users browsing this forum: No registered users and 1 guest