Application-specific context in ArgusParserStruct

[Carter Bullard]

Hey Harry,
I wouldn't "take over" any field that is in the ArgusParserStruct.   
Argus is a subset
of a larger system.  At anytime, I may bring over code that uses these  
variables,
and then you would really not be in a good position at all.

Adding a variable is a no brainer, but the name needs a little work.
I've added "void *ArgusClientContext" to the ArgusParserStruct, and it  
will
be in the next upload.

A few concepts that you need to consider.  Don't assume that there is  
only
one ArgusParser.  The design is that within the context of the callout  
routines,
there is only one valid ArgusParser, and its the one that we are  
passing.
For argus-clients, there is only one, but for other systems, there are  
multiple
ArgusParser's, so just take that into consideration, if you can.

Be sure and deallocate the ArgusClientContext in your RaParseComplete()
routine.

Carter





On Jun 3, 2009, at 10:29 PM, Harry Bock wrote:

> Hi Carter,
>
> I've come across a little snag in developing Periscope; I'd like to  
> store a pointer to a mutable context relevant only to my  
> application, without adding more fields to ArgusParserStruct and  
> without using global variables.  I've noticed that a lot of the  
> client-specific data structures are all stored within  
> ArgusParserStruct, but there is no "agnostic" field where I could  
> simply link in my own.
>
> I've worked around this by saving my context in parser->RaFlowModel,  
> which I've verified does not get modified by any Argus client  
> function that I'm using, directly or indirectly.  In the future,  
> however, I'd suggest adding a simple field like so to  
> ArgusParserStruct:
>
> struct ArgusParserStruct {
>   int status, ...;
>   ...
> +  void *context;
> };
>
> As Argus clients are currently linked statically to the common/event/ 
> parser libraries, binary compatibility shouldn't be an issue, but  
> you obviously know the direction of Argus far better than I could,  
> so I don't want to change anything sensitive.  If the change is  
> acceptable, could it be included in the final release of argus- 
> clients-3.0.1?
>
> This change would also greatly help reduce clutter in  
> ArgusParserStruct, as you could move client-specific data (such as  
> what is needed by radium, rabins, rahisto, etc) out of common code  
> and straight into the application.  I'd be more than happy to  
> contribute the patches necessary to all of the Argus clients, given  
> a week or two.
>
> -- 
> Harry Bock
> Software Developer, Package Maintainer
> OSHEAN, Inc.
> Email: harry at oshean.org
> PGP Key ID: 546CC353



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090605/84ea75b3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090605/84ea75b3/attachment.bin>