Question about Flood

[Chris Williams <ch...@cmguc.com>]

I would like to add some functionality to Flood but I want to make sure you
can't already do it.  What I would like to do is have one urllist but have
some portions of those URL's based on information from each farmer.  An
example would be to use the farmer name as part of a URL request.  Is there
any way to do this currently and if not, are there any plans.  If this can't
be done, can anyone give me some pointers of where to start looking in the
code.  I was thinking I could do something in the round_robin_get_net_url
call but I don't see any pointers to the farmer data.
Any suggestions would be great.
Thanks
Chris

Re: Question about Flood

[Aaron Bannert <aa...@clove.org>]

On Thu, Nov 15, 2001 at 12:56:41PM -0500, Chris Williams wrote:
> I would like to add some functionality to Flood but I want to make sure you
> can't already do it.  What I would like to do is have one urllist but have
> some portions of those URL's based on information from each farmer.  An
> example would be to use the farmer name as part of a URL request.  Is there
> any way to do this currently and if not, are there any plans.  If this can't
> be done, can anyone give me some pointers of where to start looking in the
> code.  I was thinking I could do something in the round_robin_get_net_url
> call but I don't see any pointers to the farmer data.
> Any suggestions would be great.

It's been awhile since I wrote that stuff, but I think you'll probably
want to write your own get_next_url handler that overrides the round
robin one. It's really a form of polymorphism, and you can even call
other get_next_url routines to do the dirty work for you.


Take a look at round_robin_profile_init(). The profile_name parameter is
used as a key to search for the root of that profile's XML subtree in the
config. It then pulls out the name of the urllist, which is again used
as the key to the XML subtree for that urllist. You'll want to write
your own profile_init routine that parses the XML any way you want.
In your case you could store the string that will be inserted into the
URLs (the farmer name or any string you want really). The place where
profile-specific opaque data is stored in the profile_t struct, which
can be defined privately per-profile.

Now you can go ahead and write you own get_next_url handler, which
knows how to take that stored string and the urllist that we parsed up
in profile_init, and produce the next URL to hit.

Let us know if you need more details or any other help with this,
Aaron