Re: [Ethereal-dev] Sponsoring development of SQL Filters & tethereal functionality

[Ober Heim <ober@xxxxxxxxxxxxxxxxxx>]

Why not just use the tethereal -T pdml |perl DBI::XML parser?

On Tue, 31 Aug 2004, Russell Samuels wrote:

> Hi,
>  
> I'm a project manager with Synomos, and we're considering sponsoring the
> development of SQL Filtering functionality and some additional
> functionality for tethereal.  If anyone who's worked on Ethereal for
> awhile can point me towards the folks with the requisite experience for
> this, I would much appreciate it.  Please touch base with me directly.
>  
> Regards,
> russells (you can guess my e-mail address from the info provided)
>  
> http://www.synomos.com 
>  
>  
> High Level Requirements:
>  
> License Requirements
> ====================
> The tool can be open source or closed source.  Access to and rights to
> modify the source code is a requirement (in order to meet future needs
> in the event that development on the product ceases).  It is preferable
> that source code created in the course of developing the tool is not
> GPLed, though it is recognized that this is impossible if GPLed code is
> determined to provide an optimal code base upon which to build the tool.
>  
> 
> Technical Requirements
> ======================
> 
> 1.0  Must provide a means to log sql communications on the wire or via a
> mirrored switch port
> 1.1  Must parse the logged data into meaninful categories, and allow the
> user to display a subset thereof:
>      -Time
>      -SQL Command / data parameters
>      -Transaction# (within any specific session)
>      -# Rows returned
>      -User login
>      -HostID
>      -IP Address (client)
>      -Port #
>      -Application
>      -Database error/warnings/messages
>      -Server
>      -Database
> 1.2  Must store sniffed data to a database for retrieval by other
> applications
> 1.3  Must do all of the above in near-real-time (max-delay of 5 seconds)
> 1.4  Must be capable of supporting high load db (e.g. thousands per
> second, with ~1000 unicode characters transaction text per transaction)
> without losing any transactions
>  
> 2.0  Must be controllable without invoking a gui (e.g. an API to control
> functionality or command-line driven)
> 2.1  Must allow the user to configure the following parameters: 
>      -S <server name>
>      -ip <server IP address>
>      -port <port no. server listens on>
>      -LS <db server to save to> 
>      -LU <username for db being saved to> 
>      -LP <password for db being saved to> 
>      -LDB <db to save to>
>  
>      Would be desirable to allow the user to configure the following
> parameters: 
>      -INCLSQL <SQL Commands to exclude, i.e. ALL except>
>      -EXCLSQL <SQL Commands to include, i.e. NONE except>
>  
> 3.0  Must support MS SQL (TDS) for SQL Server 2000
> 3.1  Would be desirable to support Oracle SQL*Net (TNS)
> 3.2  Would be desirable to support MySQL
> 3.3  Would be desirable to support Sybase
> 3.4  Would be desirable to support DB2
> 3.5  Would be desirable to support Teradata
>  
>  
>