Wow, I wasn't expecting this going in such a long thread.
On 16/12/2014 19:24, Dave Cridland wrote:
That's actually what I'm trying to avoid; we currently have lots of
fractional solutions, and no real standard.
Trying to do thing in a too generic way resolving all potential use
cases can lead to a complex and impossible to implement protocol. In my
experience and opinion, server and client developers implement XEP
according to their own need and often depending on the simplicity. Look
at XEP-0136 (message archiving) which tend to solve everything in a far
too complex way. I'm not sure it's such a big deal to have different
models if they are in simple XEPs easy to implement, and if they solve
correctly the problems.
XACML is indeed huge, and there are several specifications involved. I'm
not suggesting we make that mandatory, merely that we make that
possible, by using a model that is compatible, and using the same terms
of art used in the field.
At least, where possible.
OK, my first thought was that you wanted to implement XACML in a XEP,
but it seems that you actually want only to take inspiration of it,
right ? That make more sens. Honestly it seems really difficult to
understand well how XACML works (because of its size), but I can give a
try. My concert is that we need something *simple* and *easy to
implement*, if we want this mechanism to spread and be usable on every
server.
Yes, the question is whether we can find a mechanism which is both this
simple, and also fits the model that other systems use already.
If we stay in the same order of simplicity as the current protoXEP, I
can give a try. My question is what do you want exactly:
- write an entire new XEP with a mechanism inspired by XACML, and throw
away the current protoXEP ? In this case I would have appreciated to
have your concerns risen before, it would have saved a lot of time spent
on this protoXEP
- adapt the vocabulary of XACML to the current protoXEP ?
- take the current protoXEP as a basis, but change the workflow, i.e.
use an attribute-based access control ? I don't know if it's doable in a
reasonable amount of time, but we can try
I'd be very interested in knowing what's missing here. I'm sure other
server developers would be as well.
ejabberd is slow on creating nodes, prosody doesn't support (yet)
persistent pubsub storage, I had S2S issues with OpenFire for a long
while, RSM is nearly never implemented, etc.
Jappix and Movim recommand the use of Metronome because today it's the
only server which works correclty with them. On our project (Salut à
Toi) we use our own PubSub component (based on Idavoll), and we use a
dirty hack with Prosody. The protoXEPs were proposed to make things
clean and standard.
In addition we have some non standard experimentations on our (external)
pubsub service, and we want to try to implement before trying to
standardize. Also it's far better and quicker to develop your own
generic PubSub/PEP component, you can add what you need, experiment what
you want, etc. You can't have that with a server implementation that you
don't control.
As am I. A veto position need not be permanent, and I'm hoping we can
find the beginning of a solution, and agree a path forward, instead of
simply blocking progress.
I'm hoping too, we're putting a lot of effort to have a decent
(micro)-blogging platform on XMPP, and sometimes we have the filling to
fight against windmills.
So let me know what I can do to move forward.
Cheers
Goffi
