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

UV uv at talknet.com.au
Fri Jun 6 14:55:42 EDT 2008


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:

a.	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

b.	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

c.	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

d.	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.

e.	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:

1.	Not make that change (I think it's too late for that)
2.	Make that change for all Reply-Text responses in a way that after
the <+OK | -ERR> there's always a <LF>
3.	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." :-)

 

 

  _____  

From: freeswitch-dev-bounces at lists.freeswitch.org
[mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Anthony
Minessale
Sent: Saturday, June 07, 2008 2:58 AM
To: freeswitch-dev at 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 at 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 at lists.freeswitch.org
[mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Anthony
Minessale
Sent: Friday, June 06, 2008 9:14 AM


To: freeswitch-dev at 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 at 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 at lists.freeswitch.org
[mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Johny
Kadarisman
Sent: Thursday, June 05, 2008 2:38 PM
To: freeswitch-dev at 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 at 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 at hotmail.com
<mailto:MSN%3Aanthony_minessale at hotmail.com> 
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
<mailto:PAYPAL%3Aanthony.minessale at gmail.com> 
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
<mailto:sip%3A888 at conference.freeswitch.org> 
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org
<mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org> 
pstn:213-799-1400 


_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev at 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 at hotmail.com
<mailto:MSN%3Aanthony_minessale at hotmail.com> 
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
<mailto:PAYPAL%3Aanthony.minessale at gmail.com> 
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
<mailto:sip%3A888 at conference.freeswitch.org> 
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org
<mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org> 
pstn:213-799-1400 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20080607/776d1504/attachment-0001.html 


More information about the Freeswitch-dev mailing list