On 05/05/2015 23:01, Goffi wrote:
On 05/05/2015 16:59, Sergey Dobrov wrote:
On 01/05/2015 21:28, Goffi wrote:
Sorry I was not replying, I'm quite busy now, but am going to join you
guys ASAP, unfortunately, got a flu now.
No worries, nice to see you back.
Yes, I am aware of the issue but it can't be fixed before we have a good
way to store XML in the metadata.
OK
actually, when we got such a place some links like a comment node will
go there too.
2) published/updated
the <published/> and <updated/> elements are given by the publisher, he
can write anything he wants inside. I think that the server should
enforce these data, or we will have the same issues as in email like
mesages in the future (e.g. to appear first).
Yes, I know about this. This was made purposely to make it possible, for
instance, to import old blog posts from different source.
Would it be possible to allow enforcement as an option ? An admin can
decide to import old blogs, but an user should not be able to fake it,
or at least not in every situations.
I don't see a necessity and possibility to do that: it will require
pubsub be aware of payloads format which is not suitable, I guess.
If you think it's necessary on your service you can force it on your
pubsub but I don't see why to add such a restriction on the XEP level,
it's just too strict (and not really possible for 277).
I think an implementation note should say that the publisher or updated
field can be modified by the pubsub service, depending on the
implementation/configuration. This way a client can expect to have a
published/updated field changed by the server.
Well, we need another filtering entity here (I said about necessity of
it long time ago), which also will be used to filtering spam (or obscene
words), this way client should always expect that the payload can be
modified, but again this is not about 277, I believe.
cheers
Goffi
