Re: [OpenSPP-project] Discussion around ENUM requirements from today's team call

[David S. <dsc...@xc...>]

Hi Syed

I am fine with REST.

:D

On Jun 2, 2011, at 8:14 PM, Ali, Syed Wasim wrote:

> 
> Will there be interest in using REST based query engine to fulfill the
> role of a "resolver" to test the provisioned data. This method fulfills
> the requirement of a "resolver" and it will be faster to implement and
> write tests. In fact, the schema can accommodate the querying "rant"
> identifier within the request to enable the same end-point to buzz through
> a number of use cases without requiring complex authentication
> requirements. I can certainly lend a hand putting this together, if that
> helps.
> 
> 
> -Syed
> 
> 
> On 6/2/11 12:36 PM, "Dean Willis" <dea...@so...> wrote:
> 
>> 
>> We understand that the stakeholders really want to see OpenSPP resolve
>> ENUM queries, as that's the proof that the data model in SPPP works for
>> the target audience.
>> 
>> However, ENUM and SPPP are completely different protocols. And ENUM
>> implementations, especially performant ones, are very tricky. The use of
>> ENUM also raises questions, such as how to test SPPP's requestor-specific
>> response capability, when ENUM has no standard way of differentiating
>> requestors?
>> 
>> The design team came up with a couple of approaches.
>> 
>> 1) Build ENUM service directly into the OpenSPP server, and build an ENUM
>> client using the JavaDNS library for testing.
>> 
>> 2) Build an ENUM server that interacts at the database or Data Access
>> Objects layer with the data store behind OpenSPP, and a testing client.
>> 
>> 3) Build an ENUM server that uses the standard SPPP SOAP API to talk to
>> OpenSPP, and a testing client.
>> 
>> 4) Build an ENUM-specific web service API into OpenSPPP; such an API
>> would have the expressibility of ENUM without the baggage of theDNS
>> protocol, and would be a useful interface for adding an ENUM service to
>> OpenSPP. This API could be tested/demonstrated using something like
>> SoapUI (http://www.soapui.org), reducing the coding effort needed for a
>> client in the near term.
>> 
>> I believe the design team favored the last approach given our short
>> design/delivery cycle and the available resources.
>> 
>> We could certainly add full ENUM into the mix in a future release, but
>> don't think we're going to accomplish it in the next month.
>> 
>> How does this sound?
>> 
>> We're probably going to need help designing the ENUM-specific SOAP API.
>> Perhaps a restricted set of functionality would be adequate initially?
>> 
>> --
>> Dean
>> 
>> 
>> --------------------------------------------------------------------------
>> ----
>> Simplify data backup and recovery for your virtual environment with
>> vRanger.
>> Installation's a snap, and flexible recovery options mean your data is
>> safe,
>> secure and there when you need it. Discover what all the cheering's about.
>> Get your free trial download today.
>> http://p.sf.net/sfu/quest-dev2dev2
>> _______________________________________________
>> OpenSPP-project mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openspp-project
> 
> 
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today. 
> http://p.sf.net/sfu/quest-dev2dev2 
> _______________________________________________
> OpenSPP-project mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openspp-project