You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@juddi.apache.org by "Kurt T Stam (JIRA)" <ju...@ws.apache.org> on 2009/03/18 19:23:50 UTC
[jira] Created: (JUDDI-206) add subscription registration
add subscription registration
-----------------------------
Key: JUDDI-206
URL: https://issues.apache.org/jira/browse/JUDDI-206
Project: jUDDI
Issue Type: Sub-task
Reporter: Kurt T Stam
Assignee: Kurt T Stam
Fix For: 3.0beta
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JUDDI-206) Implement save_subscription method of
API
Posted by "Jeff Faath (JIRA)" <ju...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/JUDDI-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Faath reassigned JUDDI-206:
--------------------------------
Assignee: Jeff Faath (was: Tom Cunningham)
> Implement save_subscription method of API
> -----------------------------------------
>
> Key: JUDDI-206
> URL: https://issues.apache.org/jira/browse/JUDDI-206
> Project: jUDDI
> Issue Type: Sub-task
> Reporter: Kurt T Stam
> Assignee: Jeff Faath
> Fix For: 3.0beta
>
>
> A publisher can make subscription information to later retrieve registry data based on the subscription. Notes:
> - Subscriptions are identified by a unique key. This key can be provided by the publisher (must have owning key generator) or be generated by the system. Validation should ensure that no entities use a proposed key (and vice versa, saving entities should now check the subscription keys for clashes).
> - bindingKey and notificationInterval values are used for asynchronous notification.
> - the subscription filter input contains a collection of find_* and get_* xml messages that will be used to query the registry to get results. how should these be stored? As text blobs or serialized objects?
> - Read section 5.5.8 of spec for more information
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JUDDI-206) Implement save_subscription method of
API
Posted by "Jeff Faath (JIRA)" <ju...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/JUDDI-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Faath resolved JUDDI-206.
------------------------------
Resolution: Fixed
this has been completed (may require tweaks that will be added as future issues).
> Implement save_subscription method of API
> -----------------------------------------
>
> Key: JUDDI-206
> URL: https://issues.apache.org/jira/browse/JUDDI-206
> Project: jUDDI
> Issue Type: Sub-task
> Reporter: Kurt T Stam
> Assignee: Jeff Faath
> Fix For: 3.0beta
>
>
> A publisher can make subscription information to later retrieve registry data based on the subscription. Notes:
> - Subscriptions are identified by a unique key. This key can be provided by the publisher (must have owning key generator) or be generated by the system. Validation should ensure that no entities use a proposed key (and vice versa, saving entities should now check the subscription keys for clashes).
> - bindingKey and notificationInterval values are used for asynchronous notification.
> - the subscription filter input contains a collection of find_* and get_* xml messages that will be used to query the registry to get results. how should these be stored? As text blobs or serialized objects?
> - Read section 5.5.8 of spec for more information
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JUDDI-206) Implement save_subscription method of
API
Posted by "Jeff Faath (JIRA)" <ju...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/JUDDI-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Faath updated JUDDI-206:
-----------------------------
Description:
A publisher can make subscription information to later retrieve registry data based on the subscription. Notes:
- Subscriptions are identified by a unique key. This key can be provided by the publisher (must have owning key generator) or be generated by the system. Validation should ensure that no entities use a proposed key (and vice versa, saving entities should now check the subscription keys for clashes).
- bindingKey and notificationInterval values are used for asynchronous notification.
- the subscription filter input contains a collection of find_* and get_* xml messages that will be used to query the registry to get results. how should these be stored? As text blobs or serialized objects?
- Read section 5.5.8 of spec for more information
Summary: Implement save_subscription method of API (was: add subscription registration)
> Implement save_subscription method of API
> -----------------------------------------
>
> Key: JUDDI-206
> URL: https://issues.apache.org/jira/browse/JUDDI-206
> Project: jUDDI
> Issue Type: Sub-task
> Reporter: Kurt T Stam
> Assignee: Kurt T Stam
> Fix For: 3.0beta
>
>
> A publisher can make subscription information to later retrieve registry data based on the subscription. Notes:
> - Subscriptions are identified by a unique key. This key can be provided by the publisher (must have owning key generator) or be generated by the system. Validation should ensure that no entities use a proposed key (and vice versa, saving entities should now check the subscription keys for clashes).
> - bindingKey and notificationInterval values are used for asynchronous notification.
> - the subscription filter input contains a collection of find_* and get_* xml messages that will be used to query the registry to get results. how should these be stored? As text blobs or serialized objects?
> - Read section 5.5.8 of spec for more information
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (JUDDI-206) Implement save_subscription method of
API
Posted by "Kurt T Stam (JIRA)" <ju...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/JUDDI-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kurt T Stam closed JUDDI-206.
-----------------------------
> Implement save_subscription method of API
> -----------------------------------------
>
> Key: JUDDI-206
> URL: https://issues.apache.org/jira/browse/JUDDI-206
> Project: jUDDI
> Issue Type: Sub-task
> Reporter: Kurt T Stam
> Assignee: Jeff Faath
> Fix For: 3.0beta
>
>
> A publisher can make subscription information to later retrieve registry data based on the subscription. Notes:
> - Subscriptions are identified by a unique key. This key can be provided by the publisher (must have owning key generator) or be generated by the system. Validation should ensure that no entities use a proposed key (and vice versa, saving entities should now check the subscription keys for clashes).
> - bindingKey and notificationInterval values are used for asynchronous notification.
> - the subscription filter input contains a collection of find_* and get_* xml messages that will be used to query the registry to get results. how should these be stored? As text blobs or serialized objects?
> - Read section 5.5.8 of spec for more information
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JUDDI-206) Implement save_subscription method of
API
Posted by "Tom Cunningham (JIRA)" <ju...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/JUDDI-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tom Cunningham reassigned JUDDI-206:
------------------------------------
Assignee: Tom Cunningham (was: Kurt T Stam)
> Implement save_subscription method of API
> -----------------------------------------
>
> Key: JUDDI-206
> URL: https://issues.apache.org/jira/browse/JUDDI-206
> Project: jUDDI
> Issue Type: Sub-task
> Reporter: Kurt T Stam
> Assignee: Tom Cunningham
> Fix For: 3.0beta
>
>
> A publisher can make subscription information to later retrieve registry data based on the subscription. Notes:
> - Subscriptions are identified by a unique key. This key can be provided by the publisher (must have owning key generator) or be generated by the system. Validation should ensure that no entities use a proposed key (and vice versa, saving entities should now check the subscription keys for clashes).
> - bindingKey and notificationInterval values are used for asynchronous notification.
> - the subscription filter input contains a collection of find_* and get_* xml messages that will be used to query the registry to get results. how should these be stored? As text blobs or serialized objects?
> - Read section 5.5.8 of spec for more information
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.