|Summary:||ASTERISK-04906: [patch] [post 1.2] Allow multiple headers in UserEvents|
|Reporter:||Matthew Nicholson (mnicholson)||Labels:|
|Date Opened:||2005-08-25 20:05:19||Date Closed:||2006-03-02 12:10:12.000-0600|
|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.|
****** ADDITIONAL INFORMATION ******
With this patch multiple events can be sent using | symbols to seperate arguments.
UserEvent(Test|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.