Hi,

   I think this fifth rewrite has taken it out of prototype stage and makes it
look almost as "production" code, please tell me if it doesn't. I do not plan
to rewrite it again. I'm realy happy with what it has become.

Anyway today's MATE is just the core of an application in the application. It
has plenty of room to grow.

There are still things I will be doing on MATE's code in the very next future:

- add timers to gops so that if they expire before their stop condition the gop
   gets "marked".
  
- merge two gogs whenever a new gog matches keys of some previous unexpired gog

- spawn pre-started "empty" gops if a pdu of a gop in the gogs matches
  a given condition.

- use mem_chunks to store most of the strings in the AVP library
  * one for small strings (<16bytes)
  * one for midsized strings (<32 bytes)
  * one for large strings (<64 bytes)
  * g_malloc for the remaining cases
  
- the avpl transformations will be reimplemeted
  * a contextual_avp_op(AVPL_Transf* ctx, AVPL* src, AVP* avp, AVP* op)
    has to be written to allow to transform AVPs extracting its value from
	the source avpl and/or manupulating its contents.
  * a map method that uses a hash will replace the "extremely slow" long
    sequence of very similar matches that is used right now

- get rid of most of the dbg_print calls in the code and give sense to the
  debug levels, which by now are almost randomic.


There are things other I cannot/"do not plan to" do that would be nice
if someone else did:

- make it work with tethereal. This has frustrated me twice:
  first because I meant it to be used as a filter on live capture to save only
  packets of a call from a given number. And, second, because I tried very hard
  and failed miserably.
  
- GUI gizmos (I don't stand GUI programming, sorry) :
    an pane for sessions,
	a Graphical config tool
	?
	
- tap it, that is, we got plenty of information on how frames interact why
  don't we give the users the ability to do the math with it.