[jdev] XMPP-PubSub vs. remoteStorag

[Tobias Kräntzer]

Hi Florian,

thanks for your input.

Am 03.09.2014 um 16:30 schrieb Florian Schmaus <flo at geekplace.eu>:

> > The question is, how should the items in the collections be mapped
> > between the two APIs. remoteStorage is tree based and PubSub is
> > somehow „list-based“.
> 
> Isn't PubSub with XEP-248 (PubSub Collection Nodes) also tree based?

XEP-248 looks quite complicated. Also the proposal is deferred.

> How about:
> 
> - Use collection nodes for folders, and non-collection nodes for files
> - Folder collection nodes do not need to have any items
> - You can easily determine which node represents a folder and which is
> a file by doing a disco#info on it and determine it's type, which is
> either collection or leaf.
> - Every node has set pubsub#max_items to '1'
> - The item of a file node contains the data of the file (and maybe
> some metadata)

I also thought about this setup. This approach could also give access to older versions of an file, if the item id is some kind of hash of the file (or item). With this, the last item is always the newest. If the other items would then be older revision of the item.

I would be possible to reflect the folder structure with this approach, but there would still be a problem with the naming of the collections. Beside of this, subscribing or retrieving items would be very complicated. I would require multiple requests to get a simple folder listing.

--

After thinking more about this, I guess that the best solution would be to move the representation of the folder hierarchy to the payload.

A remoteStorage end point would be represented as a collection. This collection contains several leaf nodes representing folders. One of this nodes is somehow marked as root. The node ids have no specific meaning.

service.example.com
└── my-collection
    ├── 86A3A971 (root)
    ├── F641CEA5
    ├── 8122BD53
    ├── 
3AC0E98B
    └── 264B4792

The items are representing the content of the folder with the item id as a file or folder name.

<?xml version="1.0"?>
<iq type="result" from="service.example.com" id="items1">
    <pubsub xmlns="http://jabber.org/protocol/pubsub">
        <items node="86A3A971" x:xmlns="http://example.com/some/namespace">
            
            <item id="index.html"> <!-- content --> </item>
            <item id="main.css"> <!-- content --> </item>
            
            <item id="folder-a">
                <x:link href='service.example.com?;node=8122BD53' />
            </item>
            
            <item id="folder-b">
                <x:link href='service.example.com?;node=3AC0E98B' />
            </item>
        </items>
    </pubsub>
</iq>

This mapping would allow an easy subscription of the content of a folder. Also the subscriber would be notified, if a new subfolder has been created. The service itself could use some special options to specifies the parent folder (or node), while it is created and could automatically set an item in the other node to link to the new folder.

--

Create a new folder with the node „8122BD53“ as the parent node:

<?xml version="1.0"?>
<iq type="set" to="service.example.com" id="create">
    <pubsub xmlns="http://jabber.org/protocol/pubsub">
        <create/>
        <configure x:xmlns="http://example.com/some/namespace">
            <x:parent node="8122BD53" id="folder-c" />
        </configure>
    </pubsub>
</iq>

The service responses with the node id of the created node:

<iq type='result'
    from='service.example.com'
    id='create'>
    <pubsub xmlns='http://jabber.org/protocol/pubsub'>
      <create node='A011C46D'/>
    </pubsub>
</iq>


Subscribers would then receive a notification that a new folder has been created:

<?xml version="1.0"?>
<message from="service.example.com" to="romeo at montague.lit" id="foo">
    <event xmlns="http://jabber.org/protocol/pubsub#event">
        <items node="8122BD53" x:xmlns="http://example.com/some/namespace">
            <item id="folder-c">
                <x:link href="service.example.com?;node=A011C46D"/>
            </item>
        </items>
    </event>
</message>


--
Tobias Kräntzer
Grünberger Straße 40 | 10245 Berlin

+49-178-1353136
xmpp:info at tobias-kraentzer.de
https://tobias-kraentzer.de
Twitter: @anagrom_ataf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://www.jabber.org/jdev/attachments/20140905/db2b6880/attachment.sig>