Ethereal-dev: Re: [Ethereal-dev] Sponsoring development of SQL Filters & tethereal functionali
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
>
>
>
