Summary:ASTERISK-04906: [patch] [post 1.2] Allow multiple headers in UserEvents
Reporter:Matthew Nicholson (mnicholson)Labels:
Date Opened:2005-08-25 20:05:19Date Closed:2006-03-02 12:10:12.000-0600
Versions:Frequency of
Environment:Attachments:( 0) app_userevent3.patch
Description:Currently the UserEvent application can only send one header in the event.  This patch adds support for sending multiple events, without changing the current functionality.


With this patch multiple events can be sent using | symbols to seperate arguments.

UserEvent(Test|Header1: data|Header2: data)


Event: UserEventTest
Channel: <channel>
Uniqueid: <id>
Header1: data
Header2: data
Comments:By: twisted (twisted) 2005-08-26 00:20:26

by saying "multiple events" I assume you mean multiple headers in the event? :)

By: twisted (twisted) 2005-08-26 09:08:59

MikeJ, what was your reasoning for tagging this post-1.2?   This is a very simple enhancement to the Userevent function and would be VERY helpful to some people to be in 1.2.

By: Matthew Nicholson (mnicholson) 2005-08-26 13:37:49

Yeah, I meant multiple headers.  I am also wondering why this is tagged post-1.2.

By: Michael Jerris (mikej) 2005-08-26 16:27:33

I don't disagree that this is useful, however there are many things we are still struggling to get in that were in well before the feature freeze.  Is there a compelling reason to push 1.2 further behind schedule in this bug?

By: Olle Johansson (oej) 2005-11-22 09:06:48.000-0600

Matt, would it be possible to support "\n" as a new line marker as an alternative to "|" ?

By: Matthew Nicholson (mnicholson) 2005-11-22 10:00:48.000-0600

I don't think an actual '\n' would work because of the way the asterisk config file parser works. We could probably do a '\' and 'n' but I don't see how this is any better than '|'.  Also it complicates the code used to parse the user request. '|' is more intuitive and matches well with the rest of the dial plan.

By: Jason Parker (jparker) 2006-01-06 00:58:58.000-0600

Uploaded new patch against svn trunk.

By: Tilghman Lesher (tilghman) 2006-01-14 23:33:51.000-0600

First, we don't use malloc() for memory which only lasts within the function call.  Use ast_strdupa() for that.

Second, we have a new APP_ARGS macro API which needs to be used for all new stuff going into trunk.

By: Stefan Reuter (srt) 2006-01-15 10:10:25.000-0600

Using the macros won't work as they only support a fixed number of arguments where this patch requires vaargs style. Nevertheless you can easily use ast_app_separate_args().
For an example you might want to look at the now closed patch 6241 which does that and is shorter therfore.

By: Matthew Nicholson (mnicholson) 2006-01-15 10:28:52.000-0600

I'll look into updating this patch with that stuff.

By: Matthew Nicholson (mnicholson) 2006-01-18 13:52:55.000-0600

ast_strdupa will not work in this instance.  It only makes a copy of a string.  I need to do more than that here.  I could use alloca, but in the man page its use is discouraged.  I could use ast_malloc here instead of malloc, but I don't see any reasons not to use malloc here.

As for using ast_app_separate_args, that could be used if the number of headers that could be sent was limited.

By: Stefan Reuter (srt) 2006-01-18 15:45:57.000-0600

I think ast_app_separate_args works well in cases with a variable number of arguments. To show this i updated my patch formerly submitted as 6241 and included the documentation update proposed here.
This patch uses a fixed size char array (of MAX_SIZE_EVENTBODY bytes, currently 1024) for the eventbody and therefore does not need any dynamic memory allocation.

By: Tilghman Lesher (tilghman) 2006-01-18 16:56:33.000-0600

mnicholson:  the use of alloca() within Asterisk is not discouraged.  That is what ast_strdupa() does, in part.

srt:  your patch needlessly reimplements ast_copy_string.  Also, mentioning return values is deprecated and should be removed from the description.  And finally, you need extra spacing in your for loop to comply with the CODING_GUIDELINES.

By: Stefan Reuter (srt) 2006-01-18 17:37:29.000-0600

Thanks for your suggestions, Corydon76.
I fixed documentation and added some spaces according to the coding guidelines.
To build the eventbody the patch now uses ast_build_string. That further simplified it.

By: Tilghman Lesher (tilghman) 2006-03-01 16:27:05.000-0600

Patch needs to be updated to the latest argument parsing standards in trunk.  If I can get a patch by the end of the week, we'll get this committed.

By: Stefan Reuter (srt) 2006-03-02 03:57:35.000-0600

I dont see the APP_ARGS macros supporting a variable number of arguments, see my comment dating 01-15-06.
If there is a way to do it with the latest argument parsing standards from trunk give a hint on how that stuff works.

By: Tilghman Lesher (tilghman) 2006-03-02 10:09:22.000-0600

Currently the way we do this is that we simply set an upper limit, say 25, and allow fewer to be specified.

By: Tilghman Lesher (tilghman) 2006-03-02 12:09:19.000-0600

Please see ASTERISK-5181 -- I have modified that patch for these changes, so the generation of a UserEvent will be consistent between interfaces.