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