Just by looking at it without too much practical experience, I would say xmlrpc module is *nice*, but no more: to me it seems to complex for easy tasks (like usrloc operations or some counter inspecting) and too simple for complex tasks (SOAP indeed offers much more flexibility).

On the other hand, the module API extension for RPC seems a *very* good idea and leaves room for other protocol front ends (sercmd just as an example); maybe some work to facilitate/'standardise' implementing such front ends might be welcomed (like forking a number of children dedicated for the job or binding on some communication channels aso, which would have to be done every time). I think this is what should be made more popular and concentrate our attention on.

Although I'm a tad against web services (I haven't seen yet any big deployment using them, so, I am skeptical), so much more against using them in SER, I would not oppose the idea of having an official SOAP module: if for some small guy with 600+ subscribers it makes life easier, why not? However, I haven't seen any post with such an offer...
Since we now have modules which allow use of SER as a pocket calculator, how would you reject an enterprise *looking* like extension? :-)

WL.


On 7/29/06, Jiri Kuthan <jiri@iptel.org> wrote:
I'm digging through old archives and I am just wondering how people feel about 18
month later about the discussion about SOAP, XMl-RPC, etc. Any feedback would be
appreciated -- what you think about it now and more importantly what's your experience
if any. All in all, many are asking for a roadmap and input to that is most
welcome.


-jiri

I have an opinion on this topic too but didn't want to begin egoistically with mine :-)


At 12:48 25/01/2005, David R. Kompel wrote:
>Greger and everyone else that is interested,
>
>Please consider before ruling out SOAP, that SOAP has more off the shelf
>libraries to support it then XMLRPC. Please consider the folks that use
>Microsoft platforms for their back end processing and databases, and
>keep in mind the following:
>
>Yukon is just around the corner. It has SOAP services built in, as well
>as the ability to call SOAP services directly from T-SQL.
>
>Also we implement a carrier grade platform using SER, which is in use by
>a number of VoIP providers here, with the following extensions:
>
>1) An extra module which allows for RADIUS URI translation, extended AVP
>lookup, via extra string parameter which lets you identify what AVP
>query you wish to do, and an extra flag in the registration database
>"FOREIGN" registration, to identify a contact which has been replicated
>from another SER server.
>
>2) A service which speaks SOAP to he outside world, (it's own http
>server on non-standard port) to allow an external interface to the SER
>FIFO interface. It use is for external Voicemail MWI Notifies, and to
>send refresh, reboot and report notify messages to SIP devices.
>
>3) A generic provisioning server for almost any SIP device, which can be
>provisioned via TFTP, HTTP, or HTTPS. This server dynamically builds
>configuration files in memory on the fly for any device based on RE
>pattern matching of the filename, mapped to SQL statement, which returns
>device parameters.
>
>With just these above three things, we can implement a full carrier
>grade system, with full automated device provisioning, all CLASS 5
>features, such as unlimited level hunting, recursive call forwarding
>(even when each device in the forwarding has a different dial plan) and
>just about anything else you can think of. To accomplish this, we depend
>on SOAP as a method of component communication because we consider any
>platform, including Microsoft and the ".NET framework" as things we need
>to interact with.
>
>If your goal is to provide a framework for integrating with other
>platforms, SOAP bring a lot more flexibility to the game, and make it
>more compatible with more platforms.
>
>Remember, this is just an opinion, however it needed to be expressed,
>just so you know what other folks are doing with SER.
>
>--Dave
>
>-----Original Message-----
>From: serusers-bounces@iptel.org [mailto: serusers-bounces@iptel.org] On
>Behalf Of Greger V. Teigre
>Sent: Monday, January 24, 2005 11:29 PM
>To: Juha Heinanen
>Cc: serusers@iptel.org
>Subject: Re: [Serusers] Carrier-grade framework for SER
>
>Juha,
>Yes, I completely agree with you. However, I don't need to read the spec
>and
>far from understand it before I use it... ;-)  So I did start to look at
>
>SOAP and have very good experiences, both in terms of usability and
>scalability.
>    But, I don't have strong opinions, if the people who are going to
>use
>the interface are all against SOAP, XMLRPC is the right choice.
>
>The xmlrpc-provisioning work you have done, can it be coordinated with
>Andreas' effort?
>g-)
>
>Juha Heinanen wrote:
>> Greger V. Teigre writes:
>>
>>> As I indicated in an earlier email, I would be interested in taking
>>> part in a joint effort to further develop ser's high-availability
>>> and scalability (HAS).  I would probably have to do some development
>>> anyway, and I would prefer to see such support in the public domain.
>>> In Nov/Dec I called for responses on a SOAP-based provisioning
>>> interface, but heard nothing,
>>> so here is an overlap of interests.
>>
>> greger,
>>
>> we have done some work on xmlprc based provisioning and it looks
>> promising.  xmlrpc spec is three pages long and even i can understand
>> it.  soap spec, on the other hand, is far too thick and goes way above
>> my head.
>>
>> -- juha
>
>_______________________________________________
>Serusers mailing list
> Serusers@iptel.org
> http://mail.iptel.org/mailman/listinfo/serusers
>
>_______________________________________________
>Serusers mailing list
> Serusers@iptel.org
> http://mail.iptel.org/mailman/listinfo/serusers

--
Jiri Kuthan            http://iptel.org/~jiri/

_______________________________________________
Serusers mailing list
Serusers@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers