Joe Attardi wrote:
> On May 14, 2008, at 4:42 PM, Damian Krzeminski wrote:
>> I'll commit it: I wrote a simple test that I wanted to include.
>> Thanks for testing this.
>
> The more I look at this, the more I see that the XML-RPC API for
> FreeSWITCH mod_conference does not lend itself to the
> XmlRpcInterceptor approach well at all. It's because of the awkward
> way the API is defined. This can best be illustrated with some examples.
>
> Ex.1) To list the conferences: "conference list" - in this case, the
> command comes directly after 'conference'.
> Ex.2) To mute user #3 in the conference "MyConf1": "conference MyConf1
> mute 3" - in this case, one of the arguments (MyConf1) comes before
> the actual command (mute 3).
>
> If I understand the interceptor approach we are using, this looks to
> me like the intercepted method calls would have to look like:
> Ex.1) freeswitchApi.conference("list");
> Ex.2) freeswitchApi.conference("MyConf1", "mute", 3);
>
> I think this syntax is very awkward. Do you see what I mean?
>
> Why not re-define these API methods we're using in a more readable and
> clean format? For example, it could be something like:
> Ex.1) freeswitchApi.listConferences();
> Ex.2) freeswitchApi.conferenceMute("MyConf1", 3);
>
> If you still think we should stick with the current approach
> (XmlRpcInterceptor), I'm fine with that - but I just think the syntax
> is really ugly and counterintuitive.
>
Looks like this is XML/RPC implemented directly on top of command line
interface :-)
I think you should define the interface in a way that it makes sense for
you (I agree that: api.conferenceMute is better).
Then you have 2 options:
(1) - stick with a naive marshaller and write a freeswitch specific
adaptor that would call lower level XML/RPC proxied interface -
something like:
String listConferences() {
m_api.conference("list");
}
(2) - write a slightly more complicated marhaller
I would start with (1) and not optimize the marshaller until you have
all the information you need. Additional benefit: you have the natural
place to parse what passes for return value to something more digestible.
I think both of this options are much better than using XmlRpcClient
directly (but clearly I am biased here since I wrote the interceptor ;-)
D.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
