On 12/29/2011 12:01 AM, Matthew Wild wrote: > On 28 December 2011 10:33, Sergey Dobrov <[email protected]> wrote: >> On 12/27/2011 01:12 AM, Tuomas Koski wrote: >> > >>> On 22 December 2011 12:38, Sergey Dobrov <[email protected]> wrote: >>>> ok, sorry for wasting your time, i am closing the project. >>> >>> Never give up, never surrender! :-) >> >> I thinking now about forget about XSF and use patched module for my app. >> Anyway, if I will do any other solution, it will be not standardized. >> So, why to reinvent a bicycle if no pros found? >> > > Completely "forgetting" the XSF wouldn't be wise or constructive, in > my opinion. The XSF:
I don't want to forget it completely. I wish to continue to contribute in XEP-277. But I must to implement good integration with presences if I want to force this work. I just can't fork PEP, it's too complex thing for one person, so the only way is to create nasty hack which will be backwards compatible with XSF's standards. Please, fix me if my reasoning is wrong. > > 1) Does not claim to have published a protocol for every possible application Sure. But it have XEP-277 and it's hard to use it in real life. Moreover, my problem is fundamental problem which can disturb to implement application level protocols based on PEP. How to solve it if not with XSF? > 2) Does not force you to use only its published protocols Correct. I can republish XEP-277 if it will not be good for me. But I can't republish pubsub/PEP, it's too low level to have much versions of them. > 3) Is a community of people, and one open to contributions > > Therefore, if you really believe there is a space for a "different > PEP" then you are welcome to implement it, and submit your protocol as > a XEP. As long as it's basically sane it'll be accepted and published > as an experimental XEP. Useful links: > > - http://xmpp.org/extensions/xep-0143.html > - http://xmpp.org/extensions/xep-0001.html > I understand that. But I think that this is very bad solution to have two versions of the same protocol with the only difference in improved message filtering. Such things brake implementation of features in clients and servers. > Regards, > Matthew > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
