search

baiwyc119 / lxmppd

Automatically exported from code.google.com/p/lxmppd
0 stars 0 forks source link

mod_pubsub: Add "delete-nodes" and correct "create-nodes" #296

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Hi all,
i modify pubsub.lua and mod_pubsub.lua to support "delete-nodes" (it's 
mandatory), see http://xmpp.org/extensions/xep-0060.html#owner-delete;
and to follow the standard for 
http://xmpp.org/extensions/xep-0060.html#owner-create;

in the code there is a work-around to send notification of "delete-nodes" to 
subscribers...i work on it!

i hope it could be of help!

Original issue reported on code.google.com by serke...@gmail.com on 1 Jun 2012 at 9:05

Attachments:

GoogleCodeExporter commented 9 years ago 
Some test...some bugfix

Original comment by serke...@gmail.com on 3 Jun 2012 at 10:52

Attachments:

GoogleCodeExporter commented 9 years ago 
Thanks! Currently all focus is on the 0.9 release (which is feature-frozen), 
but I'll take a look at these as soon as it's out and I have a little more time.

Pubsub is something one area I want to bring up to scratch with the next 
release.

Original comment by MWild1 on 3 Jun 2012 at 10:57

GoogleCodeExporter commented 9 years ago

Original comment by MWild1 on 27 Jul 2012 at 1:31

GoogleCodeExporter commented 9 years ago 
Hi, i install your plugin in /usr/lib64/prosody/modules (pubsub.lua and 
mod_pubsub.lua) and i have error on prosody.log, this is it:

Oct 14 18:34:57 modulemanager   error   Error initializing module 'pubsub' on 
'jabbi.pl': /usr/lib64/prosody/modules/mod_pubsub.lua:3: attempt to call global 
'module' (a table value)
stack traceback:
        /usr/lib64/prosody/core/modulemanager.lua:35: in function 'module'
        /usr/lib64/prosody/modules/mod_pubsub.lua:3: in main chunk
        (tail call): ?
        [C]: in function 'xpcall'
        /usr/lib64/prosody/core/modulemanager.lua:35: in function 'pcall'
        /usr/lib64/prosody/core/modulemanager.lua:129: in function 'load'
        /usr/lib64/prosody/core/modulemanager.lua:88: in function '?'
        /usr/lib64/prosody/util/events.lua:67: in function 'fire_event'
        /usr/lib64/prosody/core/hostmanager.lua:84: in function 'activate'
        /usr/lib64/prosody/core/hostmanager.lua:42: in function '?'
        /usr/lib64/prosody/util/events.lua:67: in function 'fire_event'
        /usr/lib64/prosody/../../bin/prosody:374: in function 'prepare_to_start'
        /usr/lib64/prosody/../../bin/prosody:490: in main chunk
        [C]: ?

My english is bad , sorry.

Please fast reply.

Original comment by BioShoc...@gmail.com on 14 Oct 2012 at 4:39

GoogleCodeExporter commented 9 years ago 
to answer quickly.
Returns an error on line 3,
that is :
       local jid_bare = require "util.jid".bare;
does not seem to be a problem with "the code" but with 
configuration/installation of prosody

What version of prosody are you using?
Have you cp mod_pubsub.lua to /usr/lib64/prosody/modules and pubsub.lua to 
/usr/lib64/prosody/util/?

Original comment by serke...@gmail.com on 14 Oct 2012 at 5:06

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
this is the last version..

Original comment by serke...@gmail.com on 14 Oct 2012 at 5:22

Attachments:

GoogleCodeExporter commented 9 years ago 
Ok, thanks for the quick response. I did just like you wrote the new version. 
All kind of work, I added the component "pubsub.jabbi.pl" "PubSub" and search 
transports it appears. Jappix However, I do not want to work with him, crashes 
this error:

Oct 15 7:50:39 p.m. boshef462279-eaef-47d1-a03a-608834199a2c warn rid of too 
large (means the request was lost). Last rid: 687,059 New rid: 687061

The second issue, however, is vjud, prosody no crashes no errors, but transport 
is not seen in the search box, write 'damaged transport'. Maybe you have a 
revised version of this?

Original comment by BioShoc...@gmail.com on 15 Oct 2012 at 6:14

Attachments:

GoogleCodeExporter commented 9 years ago 
About to vjud and Jappix i can't help you, i never used them
but in my experience "warn rid of too large (means the request was lost)" 
refers to a BOSH request malformed or missed:
The last rid (request id) is out of sequence, this can be a warning and not a 
problem, if the difference between two rid is not so high the request is 
accepted without error. (more info here 
http://xmpp.org/extensions/xep-0124.html#rids)

Original comment by serke...@gmail.com on 15 Oct 2012 at 8:13

GoogleCodeExporter commented 9 years ago 
check this 
http://code.google.com/p/lxmppd/issues/detail?id=315&sort=-id&colspec=ID%20Type%
20Status%20Priority%20Difficulty%20Milestone%20Owner%20Summary

Original comment by BioShoc...@gmail.com on 20 Oct 2012 at 7:07

GoogleCodeExporter commented 9 years ago

Original comment by MWild1 on 21 May 2013 at 7:50