XSF Discussion - 2016-12-28

Tobias: only one child element is allowed.

Why is that?

ralphm, where does it say so in XEP-0060?

Well, 7.1.3.5.

And the schema. maxOccurs defaults to 1.

wonder what the reason was for that restriction

There was a lot of debate on this when we specced this, but consensus was that a single element made the most sense.

Treating a single thing is easier than multiple things that belong together somehow. If you need additional grouping, you can use a wrapper element.

so the recommendation is to do <item><entry><x>here the two elements</x><entry></item>

Yeah. Do you have a concrete use case for multiple elements?

Actually, <entry/> is your wrapper, and x might appear twice.

see the conversation of goffi and myself yesterday...the idea was to attach info to a pubsub atom item about the images mentioned in the item https://q.zash.se/5e4d0b8702c3.txt

so that a receiver would get further hints where to fetch the image ni:///sha3-256;wqfDv8OGw7jCvx7Dl2ZRw4FHVsKgYcOWYsO14oKsw79Nw6Q7ScO64oCaw5gKS-KCrMO4Q0o from

but since the new stanza isn't part of atom i'd have to create a new entry type, that allows atom and other children

ralphm: indeed the issue there is that entry is from atom namespace, while <reference> and <media-sharing> are XMPP

and XEP-0277 already use <entry> as item child

Why not include the meta-data inside the Atom element document?

Atom allows for arbitrary child elements

it does? that would work for me

goffi, what's your opionion on that?

I didn't knew it allows arbitraty element, in this case it works for me to

great :)

https://tools.ietf.org/html/rfc4287#section-6.1

neat

thanks ralphm, didn't knew that

ralphm, thx for the hint

https://tools.ietf.org/html/rfc4287#section-4.1.2

Right

I remember another usecase for multiple items was concurrent update of bookmarks

The trouble with concurrent updates or batching is that error handling becomes more complex. This is why batch functionality has been removed in various parts of XEP-0060.

If you still want that, you can handle it in your application-specific code.

it shouldn't be too hard to edit different items from different clients. but if everything is stored in the same item, race conditions have a more severe effect.

That's more a problem with how bookmarks work, rather that PubSub itself

Ge0rG, ralphm: we (with edehlas and chris deering) have started to work on a new protoXEP for bookmarks, which would actually be a general list of uri, you can check https://lite5.framapad.org/p/OlHwr5GBlY

one of the goal is to fix the one item for all issue

the other is to have correct handling of non MUC uri

and also nice things like tags

it cool be use not only for bookmark, but anywhere where a list or uris if useful

could*

is a bit stalled at the moment because we are all busy, be we could defenitely propose a first protoXEP quickly

goffi: right. Cool

hey, I'm at the 33c3, if someone else is here, ping me, would be nice to meet :)

edhelas: Link Mauve and daniel should be there, somewhere

mathieui, edhelas, daniel, Tobias, kalkin, I’m around Saal G, just finished eating.

And you?

just on my way to the CCH

We are around saal g right now too

I'm in the hacker room, just in front of the TARDIS and the wooden dome

kalkin, where around Saal G?

Had a chat with koolfy, about OTR and OX and OMEMO and related as well as unrelated stuff. ^^

Link Mauve: I'm currently outside where in the direction of saal1

For hacking the world?

The stairs down past the digital courage shop and right

that threema talk was a bit disappointing, btw

although there are some nice ideas on trust that could work even without their central server

Link Mauve: Welcome to the Anthropocene? Wednesday, December 28, 2016 1:00 PM, Saal2

edhelas: so where are you about?

Tobias, I'm at the Raumzeit Labor table in the dev room

edhelas: let me see if I can find that

goffi, so the example would look something like this http://ayena.de/files/xeps/sims.xhtml#usecases-microblogging