Before this last change, the event_socket responses were structured in a manner that could have been generalized as follows:

1. Command responses will always have the following structure:

Content-Type: <auth/request | command/reply | api/response | text/event-xml | log/data><LF>

[Reply-Text: <+OK | -ERR> <info payload><LF>]

[Content-Length: <info payload length><LF>]

<LF>

[<info payload><LF>]

2. If Content-Length is defined, then there’s an additional info payload after the terminating <LF> at the byte length of <info payload length>. There can be more than one Content-Length in a single event meaning there’s additional payload for this event.

3. Command response structure will be determined by the Content-Type:

auth/request

i. This response is self initiated upon creation of an event_socket connection and will expect only an auth command to follow.

ii. Will only have Content-Type field and will be waiting for authentication for 1 (?) minute

command/reply

i. This response will follow the bgapi command.

ii. The Content-Type field will be before a Reply-Text field that will appear with +OK or –ERR response

iii. When that job ended (in a request), a “Job-UUID:” label will appear in the BACKGROUND_JOB event. That event’s +OK <uuid> will correspond with all session’s events Unique-ID: <uuid>.

iv. All following events concerning this session will have that same Unique-ID

api/response

i. All Event_socket commands (except bgapi) will be immediately answered by this response before any other response.

ii. A Content-Type first

iii. Content-Length second

iv. The info-payload will include the information

text/event-xml

i. This response is for system-initiated events.

ii. The Content-Length field will appear first, then the Content-Type field.

iii. The XML/Text will appear in the info-payload data.

log/data

i. Once an Event_socket is subscribed for log information, this response will be it.

ii. The Content-Type field will appear first, then the Content-Length field.

iii. The log info will appear in the info-payload data as plain text

This last change invites an exception for the [Reply-Text: <+OK | -ERR> <info payload><LF>] policy in a way that requires more parsing rules.

To preserve consistency, I would recommend these alternatives:

Not make that change (I think it’s too late for that)
Make that change for all Reply-Text responses in a way that after the <+OK | -ERR> there’s always a <LF>
Keep it as an exception and live with it

Although this change breaks our implementation, we’d be happy to change it once there’s a decision regardless of what it is.

Disclaimer:

The info here is an extract from our _*INTERNAL*_DOCUMENTATION_ representing our limited knowledge, experience and understanding of the complex FS internals. Once this documentation proves not to be a total BS and of some true substance, it shall be wikified for the general good.

“If there are two ways to take something I've said and one of them hurts your feelings.....I meant the other one.” J

From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale
Sent: Saturday, June 07, 2008 2:58 AM
To: freeswitch-dev@lists.freeswitch.org
Subject: Re: [Freeswitch-dev] Could we have Job-UUID in a separate line?

it's already done.

On Fri, Jun 6, 2008 at 11:22 AM, Michael Collins <mcollins@fcnetwork.com> wrote:

Sounds reasonable to me. Also, since I don't hear anyone yelling and screaming about how this change will break their software I think you're safe to make the change w/o pissing off anyone.

-MC

From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale
Sent: Friday, June 06, 2008 9:14 AM

To: freeswitch-dev@lists.freeswitch.org

Subject: Re: [Freeswitch-dev] Could we have Job-UUID in a separate line?

i'll let both work
it's own header and part of the text

On Thu, Jun 5, 2008 at 4:46 PM, Michael Collins <mcollins@fcnetwork.com> wrote:

This might qualify as an "interface change" so before making the switch you should probably ask around and see if anyone has software that would break if this change were implemented.

Johny: also, since it is open source you could always add the "\n" yourself and recompile. If you haven't already tried that you might want to take it for a test drive and see if it really does what you want it to do.

-MC

From: freeswitch-dev-bounces@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Johny Kadarisman
Sent: Thursday, June 05, 2008 2:38 PM
To: freeswitch-dev@lists.freeswitch.org
Subject: [Freeswitch-dev] Could we have Job-UUID in a separate line?

Could we have Job-UUID as a separate fields. It can be parse easily, but its event easier to have it just like others response fields.

so in bgapi reply, we will get:

Content-Type: command/reply
Reply-Text: +OK
Job-UUID: e0d64b14-3327-11dd-96f6-6fa9e94f364f

Johny K.

_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org

--
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@conference.freeswitch.org
pstn:213-799-1400