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
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_userevent
Versions:		Frequency of Occurrence
Related Issues:
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) Yields 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. Thanks 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.