php http polling example

hello,
does anyone here coded a php script for http polling. i just need a
small example so i have a start. if someone can share this with me i
would be very happy.

best regards,
loic didelot.

Re: deep sixed

once upon a time

    > On Tue, 8 Nov 2005 20:05:33 -1000, you said:
    >  RB> freebsd 7-current(very) recompiled erlang ejabberd
    >  RB> ejabberd cores if v6 is enabled, runs if not
    >  RB> well, more correctly, beam cores
    >  RB>    kernel: pid 51242 (beam), uid 522: exited on signal 11 (core dumped)
    > 
    > Try to disable threads and hipe support when compiling erlang.

to solve this one, i disabled v6 and all was fine, until ...

i just cvsupped and rebuilt current  

Jan  4 04:23:24 work0 kernel: pid 73420 (beam), uid 522: exited on signal 11 (core dumped)

i have done a portupgrade -fR ejabberd

i rebuilt erlang with a hacked Makefile

#CONFIGURE_ARGS+=       --enable-threads --enable-hipe --enable-kernel-poll
CONFIGURE_ARGS+=        --enable-kernel-poll

i am now a bit worried

randy

Re: deep sixed

>>> On Tue, 8 Nov 2005 20:05:33 -1000, you said:
>>> freebsd 7-current(very) recompiled erlang ejabberd
>>> ejabberd cores if v6 is enabled, runs if not
>>> well, more correctly, beam cores
>>>    kernel: pid 51242 (beam), uid 522: exited on signal 11 (core dumped)
>>> Try to disable threads and hipe support when compiling erlang.
>> to solve this one, i disabled v6 and all was fine, until ...
>> i just cvsupped and rebuilt current  
>> Jan  4 04:23:24 work0 kernel: pid 73420 (beam), uid 522: exited on signal 11 (core dumped)
>> i have done a portupgrade -fR ejabberd
>> i rebuilt erlang with a hacked Makefile
>> #CONFIGURE_ARGS+=       --enable-threads --enable-hipe --enable-kernel-poll
>> CONFIGURE_ARGS+=        --enable-kernel-poll
>> i am now a bit worried
> Why are you worried ? Do you still have problems ?

yes.  sig 11 continues

randy

MUC / JEP-0045

Hi all,

when I read JEP-0045, I see that (section 9.1.1, workflow sequence #2):

"If this user is allowed to create a room and the room does not yet 
exist, the service MUST create the room according to some default 
configuration, assign the requesting user as the initial room owner, and 
add the owner to the room but not allow anyone else to enter the room 
(effectively "locking" the room)."

but when I create a room on an ejabberd server, it is never locked, even 
if I don't configure it. So users can join it before I configure it. Is 
it a bug in MUC implementation of ejabberd ? cause it violates the JEP.

I've tested with 0.9.8 release on debian unstable.

Thanks for this nice Jabber server guys !
Yann

Re: MUC / JEP-0045

Le Boulanger Yann wrote:
> Hi all,
> 
> when I read JEP-0045, I see that (section 9.1.1, workflow sequence #2):
> 
> "If this user is allowed to create a room and the room does not yet 
> exist, the service MUST create the room according to some default 
> configuration, assign the requesting user as the initial room owner, and 
> add the owner to the room but not allow anyone else to enter the room 
> (effectively "locking" the room)."
> 
> but when I create a room on an ejabberd server, it is never locked, even 
> if I don't configure it. So users can join it before I configure it. Is 
> it a bug in MUC implementation of ejabberd ? cause it violates the JEP.

What exactly do you send to the server? Because JEP-0045 also says that 
if you can request an instant room:

http://www.jabber.org/jeps/jep-0045.html#createroom-instant

Peter

--

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

_______________________________________________

Re: deep sixed

boys and girls, this is killing me and some users are getting
less than patient.

FreeBSD work0.psg.com 7.0-CURRENT FreeBSD 7.0-CURRENT #25: Wed Jan 4
17:49:10 UTC 2006 root <at> work0.psg.com:/usr/obj/usr/src/sys/WORK0 i386

erlang r10b9 and ejabberd freshly remade from ports

pid 784 (beam), uid 522: exited on signal 11 (core dumped)

(gdb) back
#0  0x281e114b in pthread_testcancel () from /usr/lib/libpthread.so.2
#1  0x281d941e in pthread_mutexattr_init () from /usr/lib/libpthread.so.2
#2  0x00000000 in ?? ()

randy

Re: MUC / JEP-0045

On Wed, Jan 04, 2006 at 07:12:30PM +0100, Le Boulanger Yann wrote:
> Hi all,
> 
> when I read JEP-0045, I see that (section 9.1.1, workflow sequence #2):
> 
> "If this user is allowed to create a room and the room does not yet 
> exist, the service MUST create the room according to some default 
> configuration, assign the requesting user as the initial room owner, and 
> add the owner to the room but not allow anyone else to enter the room 
> (effectively "locking" the room)."
> 
> but when I create a room on an ejabberd server, it is never locked, even 
> if I don't configure it. So users can join it before I configure it. Is 
> it a bug in MUC implementation of ejabberd ? cause it violates the JEP.

Yes. ejabberd never locks the room. And I don't see any reason (except the
word MUST in JEP-0045) why the room has to be locked after its creation.

I think that it's not a good practice to force users doing something. If user
wants to configure room, he/she can do it.

--

-- 
Sergei 'TeopeTuK' Golovan

Re: MUC / JEP-0045

Sergei Golovan wrote:
> On Wed, Jan 04, 2006 at 07:12:30PM +0100, Le Boulanger Yann wrote:
>> Hi all,
>>
>> when I read JEP-0045, I see that (section 9.1.1, workflow sequence #2):
>>
>> "If this user is allowed to create a room and the room does not yet 
>> exist, the service MUST create the room according to some default 
>> configuration, assign the requesting user as the initial room owner, and 
>> add the owner to the room but not allow anyone else to enter the room 
>> (effectively "locking" the room)."
>>
>> but when I create a room on an ejabberd server, it is never locked, even 
>> if I don't configure it. So users can join it before I configure it. Is 
>> it a bug in MUC implementation of ejabberd ? cause it violates the JEP.
> 
> Yes. ejabberd never locks the room. And I don't see any reason (except the
> word MUST in JEP-0045) why the room has to be locked after its creation.
> 
> I think that it's not a good practice to force users doing something. If user
> wants to configure room, he/she can do it.
> 

The lock is there to avoid certain race conditions, allowing people to 
discover the room before it has been properly configured (maybe the 
owner wants to require a password or make it members-only and doesn't 
want anyone to enter before setting that up), etc. If clients want 
instant rooms (no locking), they can request that.

See also the note at the end of Section 9.l.1 of JEP-0045:

Re: MUC / JEP-0045

On Wed, Jan 04, 2006 at 11:45:24AM -0700, Peter Saint-Andre wrote:
> 
> The lock is there to avoid certain race conditions, allowing people to 
> discover the room before it has been properly configured (maybe the 
> owner wants to require a password or make it members-only and doesn't 
> want anyone to enter before setting that up), etc. If clients want 
> instant rooms (no locking), they can request that.

I think that the more reasonable behaviour is to make locked rooms only when
user explicitly lcoks it.

Otherwise user (which don't read JEPs, and I think that users souldn't read
JEPs) will be confused with that lock. Moreover, users don't read server
messages, so after room is created user will be very surprised that nobody
goes to his beautiful room.

> 
> See also the note at the end of Section 9.l.1 of JEP-0045:
> 
> ***
> 
> Note: If the presence stanza sent to a nonexistent room does not include 
> an <x/> element qualified by the 'http://jabber.org/protocol/muc' 
> namespace as shown above, the service SHOULD create a default room 
> without delay (i.e., it MUST assume that the client supports "groupchat 
> 1.0" rather than Multi-User Chat and therefore it MUST NOT lock the room 
> while waiting for the room creator to either accept an instant room or 
> configure a reserved room).
> 
> ***

Re: MUC / JEP-0045

Sergei Golovan wrote:
> On Wed, Jan 04, 2006 at 11:45:24AM -0700, Peter Saint-Andre wrote:
>> Just because you don't happen to like room locking doesn't mean you can 
>> ignore the spec. Clients have plenty of options to avoid room locking if 
>> they want to.
> 
> I think that specs should be written carefully and defaults should be chosen
> with least surprise for user in mind.

IMHO this is about the client developer, not the user. A smart client 
developer will hide complexity from the user.

In any case JEP-0045 is close to final so I don't think we'll make a 
change of this magnitude now. But I'll think about it some more.

Peter

--

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd