[standards-jig] JEP-0049 Private XML Storage

Richard Dobson richard at dobson-i.net
Wed Nov 13 09:33:40 UTC 2002

> >> Why does there need to be a remove command anyway? If you query for a
> >> particular stored namespace which has not been previously stored it
> >> does not send back an error, but just sends back a blank result, why
> >> not just have it so that blank store commands are what do the delete
> >
> > Actually, it sends back a 404. Even if it didn't, storing an empty
> > element still wouldn't be appropriate, as you might want to simply set a
> > flag.
> I agree that it should send back a 404. I don't think jabberd does (but
> haven't checked) because every client I've tested against my server hangs
> you don't send back an empty private response. So Richard's suggestion is
> pretty clever way to do it if we rely on current practice.

Yes I have just checked and it does exactly what I said, if it has not been
stored already it sends back your query in a result (unless somehow the
private data of "crap:stored:data" has somehow been stored buy a client).

> I'd prefer to correct current practice though and send a 404 on no entry
> which would get us back to needing a removal command of some sort... :)
> I'd tentatively suggest a radical approach, we expand the standard iq
> This seems to come up fairly often (removing roster entries, etc) so
> iq should have the following types:
> set - set new value or update existing value
> get - retrieve value (returns 404 if value doesn't exist)
> remove - Clears value
> result - a result of any of the previous three types
> Error - in case of error
> Of course, this is a pretty major change so I guess something in the
> iq:private namespace may be more practical. :)

I think this just adding one extra type is fine for this and will allow it
to work much more properly out of the other suggestions ive seen, adding a
remove child element stops you from being able to store them should you need
to, as does attributes, but if we do not do this extra type (IMO the
preferable solution) I suggest just adding a remove attribute on the query
element as follows:

<iq type="set">
    <query xmlns="jabber:iq:private" type="remove">
        <item xmlns="namespace:to:store"/>

I think this would be a good solution and be much more inline with current
methods of removal.


More information about the Standards mailing list