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

[Ali, S. W. <sye...@ne...>]

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