not really, but I have had a bit of a think about it.
Since the existing mechanism for adding/removing nodes is via forms, I
couldn't easily add a new field per submitted value without requiring
multiple form submissions.
(could possibly do it using the 'result' type and <item> tags but I
doubt it would work.
just highlights a small limitation of the forms capability. )

So I was thinking perhaps something like this (added a delimiter and a
formatted value entry for foreign/remote nodes.) :

from
6.3.1 Only One Collection Node
"text-multi" for the "pubsub#collection" field should probably be set to true.

8. Associate an Existing Node with a Collection
Example 18. Node owner modifies node configuration

<iq type='set'
    from='ham...@denmark.lit/elsinore'
    to='pubsub.shakespeare.lit'
    id='associate1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
    <configure node='princely_musings'>
      <x xmlns='jabber:x:data' type='submit'>
        <field var='FORM_TYPE' type='hidden'>
          <value>http://jabber.org/protocol/pubsub#node_config</value>
        </field>
        <field var='pubsub#collection-delimiter'>
          <value>#</value>
        </field>
        ...
        <field var='pubsub#collection'><value>blogs</value></field>
        <field 
var='pubsub#collection'><value>pubsub.denmark.lit#blogs</value></field>
        ...
      </x>
    </configure>
  </pubsub>
</iq>

same for node config
Example 19. Node owner modifies node configuration

<iq type='set'
    from='b...@shakespeare.lit/globe'
    to='pubsub.shakespeare.lit'
    id='associate2'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
    <configure node='blogs'>
      <x xmlns='jabber:x:data' type='submit'>
        <field var='FORM_TYPE' type='hidden'>
          <value>http://jabber.org/protocol/pubsub#node_config</value>
        </field>
        ...
        <field var='pubsub#collection-delimiter'>
          <value>#</value>
        </field>
        ...
        <field var='pubsub#collection'><value>blogs</value></field>

        <field var='pubsub#children'>
          <value>princely_musings</value>
          <value>kingly_ravings</value>
          <value>pubsub.shakespear.lit#starcrossed_stories</value>
          <value>pubsub.denmark.lit#moorish_meanderings</value>
        </field>
        ...
      </x>
    </configure>
  </pubsub>
</iq>


I think this would be enough. no need to add and associate at the same
time for remote nodes, I think everything else is still ok.
All the existing messaging carries enough info for any endpoint to
target the originator if it needs to, please correct me if I'm wrong,
it's likely I've missed something important somewhere.

Other features that I think would be tremendously useful , would be
the ability for a node owner or (publisher?)
to set chainable group based, and content based filters on outgoing
data (is it already possible to filter incoming node data?). Its
possible for individual end users to set filters,
but if a node owner wants to restrict a certain group of node
subscribers from receiving notifications for certain types of data,
this would be handy.
The content based part could provide a nice way to provide
sanitisation/transformation of data en route (maybe a nice way to hook
into an esb etc from a node would be a good solution?).

thoughts?

Thanks
Jason.


.....
I sincerely hope this group considers ammending this xep.

Cheers.

-------------------------
Jason, this sounds interesting to me as well. Do you have some amendment
text to propose?

Thanks

Reply via email to