Posted by mxk on August 14, 2007 at 1:54am
This Friday I posted the third release of my library, which followed two days of public testing via the demo page. Unfortunately, very few people ran the demo and all of them were using gmail accounts, so really I didn't get any new information from that. Oh well... Today I updated the Drupal module to work with the latest library revision, documented the API, and created the server admin interface. After some testing tomorrow I'll commit all of this to Drupal CVS and make the first official release for my module. Following that, I expect to finish my patch for the subscriptions module either Thursday or Friday, which will give me two days to wrap up any loose ends before SoC final deadline.
-Max
Comments
Well, to be honest, despite
Well, to be honest, despite being a big fan of 'realtimizing' communities, especially drupal-based ones, I never really understood, even now, looking at your readme file, what this module is about. I understand that this is a 'general' something, and it's to handle notifications probably (for comments and such), but it isn't clear simply. Also I do not understand what is this client-server hiearchy - is it about a 'notification daemon' with subscribed entities, or is it a jabber (routing) server?
Also, requiring register globals (which is a feature easy to avoid by anyone with a better understanding of programming in general, yet if a code was written with this, it's hard or even impossible to get rid of it) prevents me from installing it to one of my own systems, for simple security reasons.
Do not use register globals at all - it QUESTIONS code quality for most of administrators.
And write example scenarios, be more clear, because if even I cannot understand your approach - not too much experience with drupal, but years with PHP and XMPP in general - then it'll be hard to spread this.
Erm...
Ok... From the module readme - "This module provides Drupal with an API through which it is possible to send users instant messages." Which part of that are you confused about? It gives you a set of functions that use XMPP protocol to send messages to specified jabber ids. I'm not really sure how else to say that to make it clearer.
That's one part of my project, the other is a modification of the existing subscriptions module to demonstrate this new API. The modification will allow users to select how the notifications are delivered - via e-mail (current method), or via IM (new method). As explained in my update, this part will be done in the next few days, but you'll also find finished library examples in the example directory.
For the client-server hierarchy - the client sends messages, the server routes them, as per XMPP specs.
Your next point really got me scratching my head for while, enough so to actually go back and check what I wrote. I'm not sure where you got your information on register globals, but once again from the readme, system requirements section - "register_globals = Off", along with safe_mode and magic_quotes_runtime.
-Max
OK, I'm sorry, I was a bit
OK, I'm sorry, I was a bit sloppy on reading that file; so will be a lot of admins. I just read 'required' 'register globals', and it made me skip the 'on-off' part. (That's the usual People Don't Read principle - you read novels, but you "scan" everything else). BTW, it's also a security flaw if something "needs" register globals off - this means that if installed on a not-properly configured server, it could make security problems. I hope that drupal warns about that, and since it's a second level threat, most developers don't care about this anyway.
Again if it's a sending-only thing, why to have a server? Is it an XMPP server, which turns on only when there's a message to send, builds an s2s connection, sends available presence for its clients,then when the client has sent the message, and disconnects, it shuts down? Strange behaviour...
(btw, what I'd like is to have a 'client pool' for XMPP-PHP: this means, having a real daemon, which runs always, and a PHP XMPP client connects to it with a handler, gets all the messages the corresponding jabber entity received while PHP wasn't present, and/or would be able to 'wake up' PHP on messages - but certainly to bridge PHP's original start-on-demand and jabber's always-on method of work; I know a PHP process can run forever in some circumstances, but it makes headaches to sysadmins.)
Forgive me if I'm too stupid: I'm just playing the layman's role :)
But it seems it's a communication-only issue, let's see by detail:
Very formal; when I read it, I thought it's a distributed middleware solution with jabber for PHP. Of course I did not read the rest of the paragraph (thought it would be an expansion of the first sentence.)
260 if ($values['xmpp_client_transport'] == 'webtcp') {261 $passwd = variable_get('xmpp_server_secret', '');
262 form_set_value($form['client']['xmpp_client_auth_passwd'], $passwd);
263 $values['xmpp_client_auth_passwd'] = $passwd;
Is it an XMPP component ("server_secret") or is it a client? ("client_auth_password")
Trust me I'm not mocking or anything, I'm just confused because I'm sloppy, and most users will be sloppy too, since we're busy, since that's life... the code is clean and demanded, it's just some communication issue..
No problem
The only reason my library "requires" register_globals off is because I do not test with it. In reality, since I don't use any global variables there should be no security issues. PHP 5 has register_globals off by default and PHP 6 removes that option completely. Writing software that treats register_globals=On as an error should hopefully prepare people for the time when they are no longer given an option to turn it on. And by the way, if you actually try to use the library as is with register_globals=On it will throw an exception at you. You have to tell it to skip environment checks if you still want to use it with your current configuration.
For the server, here's the reason for that strange behavior... First of all, if you read the posts on my dev site you will see that I repeatedly advise people to run their own jabber servers if at all possible. My PHP solution will never be able to compete with something like ejabberd, openfire, or any other server software. So, if the person is able to run such server, they have no need for mine and the problem is solved. What people wouldn't be able to run a dedicated server? Those that are on shared hosting, and perhaps only have FTP access to their websites. My server is made for those people only. All it does is allow them to send messages out. The choices are either that or nothing at all. Receiving doesn't work because there can't be a dedicated server process. Again, if they have the ability to run such process, then they should also be able to run some other server software.
My server operates on client's demand. When there is something to be sent, the client activates the server, transmits outgoing stanzas, and closes the connection. The server accepts incoming messages, routes them to the appropriate destination and shuts down. The web server software, in this case, is what provides concurrency. If there was a way to achieve the same effect in PHP, it would solve all the problems. However, there is no threading capability and something like fork (pcntl_fork) is only available via an optional extension that is not installed on most shared hosting accounts, and is not available at all on windows.
The code that you posted there is actually going to be removed. The module isn't finished yet because I ran into some last-minute problems with the server's ability to talk with ejabberd. Has to work on that first and am about to go back to the module. When using the client with a dedicated server over TCP you obviously need to provide the jid and password to authenticate with. For my server, there is an external security mechanism to prevent someone who isn't authorized from activating the server in the first place. That's what server_secret is for. It does the exact same thing as a password, but it is used in a different place. In order for the client to activate the server it needs to make a request to something like http://drupal.org/xmpp/server/[server_secret]. If the secret is correct, the server activates and allows client to connect. Since this security mechanism is in places to protect the server, when it comes time for the client to perform authentication the password is ignored. Server allows the client to use any JID since the client is already authorized, and no other client besides my own can connect to the server.
-Max