openspp-project Mailing List for OpenSPP (Page 2)
Status: Planning
Brought to you by:
deanwillis
Menu
▾
▴
openspp-project — Participants in the OpenSPP Project, including Development Team,Owner, etc.
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(39) |
Jul
(3) |
Aug
(23) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ali, S. W. <sye...@ne...> - 2011-07-12 01:06:33
|
Already, I am going home after this. Just a couple of minor fixes on this update. Take care. On 7/11/11 9:01 PM, "int...@ie..." <int...@ie...> wrote: >A new version of I-D, draft-ietf-drinks-spprov-09.txt has been >successfully submitted by Syed Ali and posted to the IETF repository. > >Filename: draft-ietf-drinks-spprov >Revision: 09 >Title: Session Peering Provisioning Protocol >Creation date: 2011-07-12 >WG ID: drinks >Number of pages: 96 > >Abstract: > This document defines a protocol for provisioning session > establishment data into Session Data Registries and SIP Service > Provider data stores. The provisioned data is typically used by > various network elements for session peering. > > This document describes the Session Peering Provisioning Protocol > used by clients to provision registries. The document provides a set > of guiding principles for the design of this protocol including > extensibility and independent transport definitions, a basic data > model and an XML Schema Document. > > > > > >The IETF Secretariat |
|
From: Ali, S. W. <sye...@ne...> - 2011-07-11 23:59:34
|
Hi guys, Just an fyi. New sppp draft has been published. Thanks, -Syed On 7/11/11 7:23 PM, "int...@ie..." <int...@ie...> wrote: >A new version of I-D, draft-ietf-drinks-spprov-08.txt has been >successfully submitted by Syed Ali and posted to the IETF repository. > >Filename: draft-ietf-drinks-spprov >Revision: 08 >Title: Session Peering Provisioning Protocol >Creation date: 2011-07-12 >WG ID: drinks >Number of pages: 96 > >Abstract: > This document defines a protocol for provisioning session > establishment data into Session Data Registries and SIP Service > Provider data stores. The provisioned data is typically used by > various network elements for session peering. > > This document describes the Session Peering Provisioning Protocol > used by clients to provision registries. The document provides a set > of guiding principles for the design of this protocol including > extensibility and independent transport definitions, a basic data > model and an XML Schema Document. > > > > > >The IETF Secretariat |
|
From: joshi v. k. <vij...@ya...> - 2011-06-29 02:41:56
|
Curious to know whether DB/DAO code is working as expected. Let me know if you are experiencing any issues. Thanks Vijay |
|
From: David S. <dsc...@xc...> - 2011-06-24 16:01:50
|
I would wait until after next sprint. No need for distractions yet. :D On Jun 24, 2011, at 6:59 PM, Dean Willis wrote: > > > Now that we're moving along and have a framework, we may want to bring the DRINKS working group's attention to OpenSPP. > > While it's doubtful that anybody will jump in to help with the code, we might start getting some interest in testing and review. > > > If we're going to do this, how shall we proceed? Any of us could reasonably introduce the project on the DRINKS mailing list. But it's possible that our stakeholders might have some sort of preferred approach... > > What do y'all think? > > -- > Dean > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense.. > http://p.sf.net/sfu/splunk-d2d-c1 > _______________________________________________ > OpenSPP-project mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openspp-project |
|
From: Dean W. <dea...@so...> - 2011-06-24 15:59:58
|
Now that we're moving along and have a framework, we may want to bring the DRINKS working group's attention to OpenSPP. While it's doubtful that anybody will jump in to help with the code, we might start getting some interest in testing and review. If we're going to do this, how shall we proceed? Any of us could reasonably introduce the project on the DRINKS mailing list. But it's possible that our stakeholders might have some sort of preferred approach... What do y'all think? -- Dean |
|
From: Dean W. <dea...@so...> - 2011-06-24 15:08:36
|
Report on OpenSPP Sprint 1Demo 20110624 Attending: Jean-Francois, Jeremy, Mickael, Vijay, Dean Notes by Dean Attempted to use Dean's Asterisk bridge for voice and failed; callers after third were going to voice mail at the telephony gateway provider. Switched to Skype successfully. Used "join.me" screen sharing service, with Jeremy controlling the screen sharing. Demoed code in SVN, presence of OSS licensing, building from Ant in Eclipse, and execution of SPPP SOAP/HTTP API in a Tomcat container (co-located on Jeremy's PC) using the SoapUI client simulator. Return values for the demo were hardcoded as the "middleware" layer connecting the API to the database is incomplete and being moved to Sprint 2. Following the demo, we transitioned to a discussion of the project and planning for future work. Jean-Francois suggested more emphasis on proving the protocol works. In short, more protocol transactions. Given that once the command and schema are completed, most of the add/change/delete operations are "easy", Vijay suggested adding the route group operations to Sprint 2. Proposed: Sprint 2 focuses on code completion, runs until July 8 with review meeting July 11. Add route group operations to backlog. Sprint 3 focuses on deployment, runs July 12 to July 18 with review meeting July 19, should give us demonstration capability for IETF. We can train-up presenter for IETF July 20-22. |
|
From: Dean W. <dea...@so...> - 2011-06-24 13:11:05
|
We're having trouble with my SIP-based bridge, so are switching to Skype. -- Dean |
|
From: Dean W. <dea...@so...> - 2011-06-24 12:55:10
|
Use: https://join.me/849-897-479 -- Dean |
|
From: Dean W. <dea...@so...> - 2011-06-23 15:56:41
|
We've wrapped up Sprint 1, and following the Scrum methodology are preparing to demonstrate the delivered objectives to the stakeholders. Not all objectives were completed in the timeframe, and (as per Scrum) are being rolled-forward into the next sprint. A sprint conclusion report draft is in the project wiki at: https://sourceforge.net/apps/mediawiki/openspp/index.php?title=Sprint_1 We'll be demoing the completed objectives to stakeholders on Friday, June 24 at 0700 MDT, 0800 CDT, 0900 EDT, 1300 UST. Callin-in information We'll try using my Asterisk conference bridge for the cal, and the "join.me" screen sharing service for the demo. To access the bridge: 1) By phone: +1 214 504 1987, select option 3 from IVR, pin 777 2) By SIP, sip:dea...@pb..., option 3, pin 777 3) By Googletalk/Jingle: dea...@so..., option 3, pin 777 (this one's not well-tested yet) or GV-call to +1 972 853 1394 We'll use the join.me screen-sharing service for watching the demo. Jeremy or I will send out a URL shortly before the call. This will connect to a site that downloads a Java applet, and should work with any modern browser. If there's a problem with my Asterisk bridge (it's recently been set up and not extensively tested) we may fall-back to a join.me dial-in number, which we'll push out if needed. -- Dean |
|
From: Dean W. <dea...@so...> - 2011-06-23 00:33:51
|
I'll be sending out more details shortly, but wanted to get a quick update out so people know how to plan. We're not QUITE ready to demo the results of Sprint 1. So Thursday AM, the team will meet, work through a practice demo and Sprint review. 0700 MDT, 0800 CDT, 1300 UST If that goes as expected, we hope to be able to demo to available stakeholders on Friday morning, using Sumanth's GotoMeeting account. -- Dean |
|
From: joshi v. k. <vij...@ya...> - 2011-06-18 10:15:16
|
My apologies for sending it late. In the AM had a productive call with Jermey over skype. We went over DAO and DTO and how we plan to use them. We decided on using single jar file for Sprint 1. Jermey will send service and business layer code to me for better understanding which may help during the integration. Now able to run same code under tomcat. next complete and check in remaining code.Need to enhance Organization DAO/DTO. issues none. Thanks Vijay |
|
From: Dean W. <dea...@so...> - 2011-06-16 14:11:58
|
Attending: Vijay, Jean Francois, Jeremy, Dean. Notes by Dean Summary: Code for each developer group is coming together, but has not yet been integrated into a deployable whole. We are shooting to be able to demo the three basic transactions on Destination Group on the June 23 call. This means we'll need to start pushing integration over the weekend. Status report: Vijay Created data model for destination group and checked in code for it. Created Data Access Object for those transactions with database persistence. Next step is to get it running under the Tomcat container. Also need to verify compliance with coding guidelines. open question on transforming string identifier to numeric ID. Now doing a database lookup for this. Need to work more with Jeremy on package names and getting into deployment server. Discussed string-to-number mapping. Probably need to have a schema walkthrough technical meeting. For example, which identifiers must be unique? Which ones do we use as primary or composite keys? Some of this can push to next sprint. Status report: Jeremy Samuel and Mikkael have been working on CXF for service environment. They have generated out a service stub. They are having a deployment issue with the namespace of the endpoint; not finding the endpoint under Tomcat. They are also using SoapUI to test. Jeremy is working on the command processing logic. he will shortly send out some emails on package names and package contents. Also will start working on exception architecture, which has to encompass the Spring exception model. Mikkael and Samuel are working on Log4J usage and need to nail down some conventions for usage. Issue: Coding guidelines and comments in documentation. Some of the code is generated by a tool; this could does not conform to the guidelines. Some of this code can be dynamically generated from Ant, other of it requires hand-modification post-generation and therefore cannot be dynamically generated and will be checked into SVN. Jean-francois asked Jeremy to send out an email explaining this so that CableLabs can approve this variation from contracted coding guidelines. Discussion of packaging: Proposed that we could put everything in one big JAR for now. More discussion will follow. Discussion of exceptions followed. Proposed that the business logic layer should catch all lower-layer exceptions and turn them into something reasonable for the client. This raises questions for logging of exceptions and will need to be dealt with as part of Log4J process. Question: Does protocol spec provide for strength-length limitation responses? Dean reported on the dev/test server. We need to define process checkpoints for moving onto the server. Discussion of Process: Ant has targets that check out code from SVN, onto build server, run through deployment scripts, create databases, etc. Noted that dropping the database between releases may require repopulating the database with reference data. Vijay proposes database core scripts in SVN so that we can rebuild quickly. When do we expect to start putting "stuff" onto the dev/test server? Need to get service layer, command layer, DAO, schema, and Ant. Can we have demonstration by next Thursday? This means we need to start trial integration Sunday. Vijay and Jeremy to talk at 0730 EDT Friday. Topics: conventions, logging, exceptions, how we see integration coming together, and design questions around commands and CXF, DTO, DAOs, ANT scripts. Question: What does the demo look like? Envision using soapUI running shared-screen from GotoMeeting or (something similar). Demonstrator will show the add, get, delete, and get(not found) operations on a single destination group. |
|
From: Dean W. <dea...@so...> - 2011-06-16 13:06:04
|
J-F says the 303 number has expired. The "local" number is now: +1-678-809-2365 Bridge PIN: 1197615 -- Dean |
|
From: Dean W. <dea...@so...> - 2011-06-16 13:02:00
|
I seem to be having trouble with the 303 number for the bridge. The nice lady says "thank you for calling" and then hags up. The 888 number works, but we're waiting for J-F to"leader" in... -- Dean On Jun 15, 2011, at 3:25 PM, Dean Willis wrote: > > We're making good progress with the development phase, and would like to have the development team and interested others (especially the "subject matter experts" ) on tomorrow's call: > > 0800 US-CDT > 0900 US-EDT > 1300 GMT > > > Jean-Francois has agreed to provide a bridge: > > +1 888 742 8686 / +1 303 928 2600 > 119 7615 |
|
From: Dean W. <dea...@so...> - 2011-06-15 20:26:07
|
We're making good progress with the development phase, and would like to have the development team and interested others (especially the "subject matter experts" ) on tomorrow's call: 0800 US-CDT 0900 US-EDT 1300 GMT Jean-Francois has agreed to provide a bridge: +1 888 742 8686 / +1 303 928 2600 119 7615 |
|
From: Dean W. <dea...@so...> - 2011-06-09 16:00:34
|
On today's team call, we discussed that we need to "get a handle" on our use of the Sourceforge Tracker system. Along these lines, I've created categories for "Product Backlog", "SPrint 1", and "Demo Server" in the Feature Requests" tracker, and added my to-do's from today's calls to the tracker. I've also verified that the dev-team members have rights. Note that you "stakeholder" folks are welcome to use the tracker. You'll need to set yourself up with SourceForge IDs and communicate those to me. Eyeball it here: https://sourceforge.net/tracker/?group_id=550436&atid=2234012 -- Dean Willis |
|
From: Dean W. <dea...@so...> - 2011-06-09 14:51:03
|
Here are my notes from this morning's call. They are being archived (and revised as needed) on the wiki. --------------------------- Open SPP Team Call, Thursday June 9, 2011 Attending: Jeremy, Vijay, Jean-Francois, Dean Notes by Dean Dicussion: OSS components and software licensing as rferred to CableLabs legal. A formal decision is still pending, but Jean-Francois and team are recommending (to Legal) the approach suggested by the dev team, and the team is to proceed with the proposed OSS components and the Apache Version 2 license for now. Discussion: Sprint 1 Backlog Slipping start date to tomorrow and finish date to 6/18/11 Remove audit from sprint backlog (Action: Dean) Discussed use of database persistence vs. in-memory. Agreed that we will attempt to get the database persistence model to work in Sprint 1, using Spring/JDBC. (Lead: Vijay) Do we attempt Syed's ENUM-like REST API in Sprint 1: No, but the product backlog needs to be amended to include it (Action: Dean to edit product backlog). How do we incorporate M&S in Sprint 1? Leaning towards asking them to handle the SOAP service interface stuff. Jeremy and David will meet with them Monday. (Action: Jeremy to report back to team.) How are we going to do exception handling? We'll work out a minimal approach for Sprin 1, and mature over the development process. (Action: Dean to add proper exception handling to product backlog) Do we need a hosted platform for Sprint 1? Probably. We could use an Amazon virtual server or work on Dean's server at softarmor for now. (Action: Dean to set something up, communicate to team). Object/relational mapping schema: Vijay proposed using numeric IDs instead of object name for mapping. No objections noted. String size limitations relating database schema need to be resolved with the protocol specification. (Action: Dean to Add string size limitation/validation issues into product backlog.) Internationized Strings: The current geenral direction is to internationalize all proper names. Easiest approach appears to be to be to use UTF-8. This does raise questions from a protocol perspective, especially around string comparison. Further discussion with Ken is probably required. (Action: Dean to add Internationalization, UTF-8 selection into product backlog) Task division: Data model, Spring JDBC connector, DAO: Vijay to lead. Service Interface: Mikkael, Samael working with Jeremy on SOAP envelope Command processing stub: Jeremy Exception architecture: Jeremy to lead discussion on list. Component architecture: What goes into each JAR file, etc. To discuss on team mailing list. Further items: Discussion on tools/support. We probably need to get a handle on use of Tracker. Action: Dev team to start "Daily Standup" emails on Monday. Each day, we each report by email to the team list. Each such report should address 1) What I have done in the past 24 hours. 2) What I plan to do in the next 48 hours. 3) Any problems/obstacles that I am hitting. -- Dean Willis |
|
From: Dean W. <dea...@so...> - 2011-06-09 14:43:21
|
As the dev team understands the SPPP specs, most string lengths are unbounded. This is a problem for the use of MySQL as a persistence model, at least with Spring/JDBC, as the database schema gets fixed-size strings. Two questions: 1) What sizes are reasonable for each of the strings in the schema? 2) Do we need something in the protocol to inform the client of permitted string sizes and/or to add bounds-checking and reporting in the transaction logic? -- Dean Willis |
|
From: Dean W. <dea...@so...> - 2011-06-09 14:39:53
|
We may need to think about internationalization in SPPP. I'm not sure that the protocol drafts have a complete answer to internationalization questions. The dev team is presuming use of UTF-8 encodings in OpenSPP. We may need to nail this down in the protocol specs. Experience indicates that string comparison is an especially tricky bit to get right. -- Dean Willis |
|
From: Dean W. <dea...@so...> - 2011-06-09 13:02:22
|
> > > Is there a conference call today? > > Yes. Given that folks outside of the dev team seemed to be "away", I had only invited the dev team, but all are welcome. -- Dean |
|
From: David S. <dsc...@xc...> - 2011-06-09 12:45:45
|
Hi Dean I got this as well. Tnx, :D On Jun 7, 2011, at 4:57 PM, Dean Willis wrote: 1) We're waiting on approval for the proposed open-source components and licensing terms. Should we proceed without formal approval in anticipation of being approved? 2) I'm not sure this list is working right. I see the following persons subscribed: dea...@so...<mailto:dea...@so...> dsc...@xc...<mailto:dsc...@xc...> je...@di...<mailto:je...@di...> jf...@ca...<mailto:jf...@ca...> kca...@tn...<mailto:kca...@tn...> mel...@gm...<mailto:mel...@gm...> mic...@gm...<mailto:mic...@gm...> su...@ca...<mailto:su...@ca...> sye...@ne...<mailto:sye...@ne...> vij...@ya...<mailto:vij...@ya...> but I haven't seen posts/messages from several project members. Everybody getting this? Please respond in the affirmative if you see this message. -- Dean <ATT00001..c><ATT00002..c> |
|
From: Jean-Francois M. <jf...@ca...> - 2011-06-09 12:36:36
|
Hi Dean and all, I was out for a few days and have not looked at this since I returned on Tuesday. Proceed without formal approval for now – I will try and close my action item on this by Monday COB. Is there a conference call today? Jean-Francois. From: Dean Willis <dea...@so...<mailto:dea...@so...>> Date: Tue, 7 Jun 2011 07:57:42 -0600 To: "ope...@li...<mailto:ope...@li...>" <ope...@li...<mailto:ope...@li...>> Subject: [OpenSPP-project] PROJECT STALLED: ACTION REQUIRED 1) We're waiting on approval for the proposed open-source components and licensing terms. Should we proceed without formal approval in anticipation of being approved? 2) I'm not sure this list is working right. I see the following persons subscribed: dea...@so...<mailto:dea...@so...> dsc...@xc...<mailto:dsc...@xc...> je...@di...<mailto:je...@di...> jf...@ca...<mailto:jf...@ca...> kca...@tn...<mailto:kca...@tn...> mel...@gm...<mailto:mel...@gm...> mic...@gm...<mailto:mic...@gm...> su...@ca...<mailto:su...@ca...> sye...@ne...<mailto:sye...@ne...> vij...@ya...<mailto:vij...@ya...> but I haven't seen posts/messages from several project members. Everybody getting this? Please respond in the affirmative if you see this message. -- Dean |
|
From: Ali, S. W. <sye...@ne...> - 2011-06-07 17:25:24
|
Updated version. -Syed On 6/7/11 10:38 AM, "Ali, Syed Wasim" <sye...@ne...> wrote: > >Hi guys, > >Attached are the proposed sample REST queries that mimic a resolver. It >took me longer to write this document then what it would take to generate >working stub code for the implementation. I briefly ran this by Vijay >yesterday (taking advantage of the proximity) and, short of implementing a >compliant ENUM and/or SIP interface, this appears to be a good first step. >It will also make writing QA tests a breeze. > >Let me know if there are any suggested updates or general comments. Next >step is to write conforming XML schema for the response text, where >applicable. While some object definitions can be re-used from SPPP schema, >I think it is best to keep the resolver schema separate from SPPP >document. > >Thanks, > >-Syed > > > > >On 6/2/11 2:35 PM, "David Schwartz" <dsc...@xc...> wrote: > >>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 >> > |
|
From: Ali, S. W. <sye...@ne...> - 2011-06-07 14:54:10
|
Hi guys, Attached are the proposed sample REST queries that mimic a resolver. It took me longer to write this document then what it would take to generate working stub code for the implementation. I briefly ran this by Vijay yesterday (taking advantage of the proximity) and, short of implementing a compliant ENUM and/or SIP interface, this appears to be a good first step. It will also make writing QA tests a breeze. Let me know if there are any suggested updates or general comments. Next step is to write conforming XML schema for the response text, where applicable. While some object definitions can be re-used from SPPP schema, I think it is best to keep the resolver schema separate from SPPP document. Thanks, -Syed On 6/2/11 2:35 PM, "David Schwartz" <dsc...@xc...> wrote: >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 > |
|
From: Dean W. <dea...@so...> - 2011-06-07 13:57:49
|
1) We're waiting on approval for the proposed open-source components and licensing terms. Should we proceed without formal approval in anticipation of being approved? 2) I'm not sure this list is working right. I see the following persons subscribed: dea...@so... dsc...@xc... je...@di... jf...@ca... kca...@tn... mel...@gm... mic...@gm... su...@ca... sye...@ne... vij...@ya... but I haven't seen posts/messages from several project members. Everybody getting this? Please respond in the affirmative if you see this message. -- Dean |
1 message has been excluded from this view by a project administrator.
