Bug#619347: testing the Jappix package from mentors
Hi Philippe, I've just tested your Jappix package from mentors My testing is biased: I already had ejabberd running and I had already used BOSH to integrate with the Candy chat client so my server was able to run Jappix very quickly. It took me all of about 5 minutes to get it going. So far, I feel the Jappix chat client is more reliable for both group chat and private chat than the Candy client. The Candy client would get into a bad state after trying to start any private chat. It was very easy for me to just disable the stuff in /etc/apache2/conf.d/jappix.conf and set it up in a virtual host. In my Apache2 virtual host, I used the following to force it to work with my ejabberd: RewriteEngine On # for Candy: RewriteRule ^/example/http-bind/ http://ejabberd-host:5280/http-bind/ [P] # for Jappix: RewriteRule ^/http-bind http://ejabberd-host:5280/http-bind/ [P] Various issues: - I feel there are a lot of options in the Jappix setup wizard. People not familiar with Jabber may not know all the server names they need to insert and the guesses are not going to be correct for a high percentage of users. This is an issue for upstream to improve. - the user login form: there should be an easy way to customize it, many people will just want the user logged in anonymously, without the full form. Candy has various login modes, in one case, it just asks the user to choose a nick name. - at one point, my Firefox test login dropped out of the chat session with Internal server error but it was happy to log in again 5 seconds later and showed the missed messages - I don't think the setup wizard should appear the first time somebody browses to the page: the admin password should be set during installation perhaps. With Drupal, it is necessary to browse to install.php to force the setup wizard to run, so random visitors don't start Drupal setup by accident. This is not highly secure either, but it removes some risk of random chance. - Please add a README.Debian - if you can, include something in README.Debian about how people can integrate Jappix into their existing web site - it would be particularly interesting if you provide, under /usr/share/doc/jappix some sample ejabberd.cfg or a diff from the default Debian ejabberd.cfg - I had to enable the mod_http_bind module, declare a new domain for my anonymous web users and then declare that http_bind was permitted for that domain. - when I installed the .deb package, it tries to restart apache although I have apache2, so it gives an error: [ ok ] Reloading web server config: apache2. Setting up jappix (0.9.8+dfsg-1) ... invoke-rc.d: unknown initscript, /etc/init.d/apache not found. [ ok ] Reloading web server config: apache2. - the font you mentioned in an earlier email - is there any reason it couldn't be listed in a separate source package in your control file? Regards, Daniel -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e5637d.9080...@pocock.com.au
Bug#619347: testing the Jappix package from mentors
Hi Daniel, Thanks for testing the package. I am not a member of the upstream developers, but they have been very responsive to our comments so far. My testing is biased: I already had ejabberd running and I had already used BOSH to integrate with the Candy chat client so my server was able to run Jappix very quickly. It took me all of about 5 minutes to get it going. So far, I feel the Jappix chat client is more reliable for both group chat and private chat than the Candy client. The Candy client would get into a bad state after trying to start any private chat. It was very easy for me to just disable the stuff in /etc/apache2/conf.d/jappix.conf and set it up in a virtual host. In my Apache2 virtual host, I used the following to force it to work with my ejabberd: RewriteEngine On # for Candy: RewriteRule ^/example/http-bind/ http://ejabberd-host:5280/http-bind/ [P] # for Jappix: RewriteRule ^/http-bind http://ejabberd-host:5280/http-bind/ [P] I will add this line to the /etc/apache2/conf.d/jappix.conf file (possibly commented out). This is also the configuration I was using on Apache. Various issues: - I feel there are a lot of options in the Jappix setup wizard. People not familiar with Jabber may not know all the server names they need to insert and the guesses are not going to be correct for a high percentage of users. This is an issue for upstream to improve. - the user login form: there should be an easy way to customize it, many people will just want the user logged in anonymously, without the full form. Candy has various login modes, in one case, it just asks the user to choose a nick name. - at one point, my Firefox test login dropped out of the chat session with Internal server error but it was happy to log in again 5 seconds later and showed the missed messages Ouch. The Debian bug tracker will probably not permit bug reports against the package yet. It should be added to the upstream bug tracker. Anonymous mode by default should not be difficult to implement and I think it would be useful. - I don't think the setup wizard should appear the first time somebody browses to the page: the admin password should be set during installation perhaps. With Drupal, it is necessary to browse to install.php to force the setup wizard to run, so random visitors don't start Drupal setup by accident. This is not highly secure either, but it removes some risk of random chance. Great idea. I will ask the Jappix developers for guidance and adapt the default configuration based on their answer. - Please add a README.Debian - if you can, include something in README.Debian about how people can integrate Jappix into their existing web site This is definitely needed. - it would be particularly interesting if you provide, under /usr/share/doc/jappix some sample ejabberd.cfg or a diff from the default Debian ejabberd.cfg - I had to enable the mod_http_bind module, declare a new domain for my anonymous web users and then declare that http_bind was permitted for that domain. I have been running Prosody for some time so I'm a bit unfamiliar with ejabberd. If you can describe the changes to the configuration, I will include them in the aforementioned README.Debian file :) - when I installed the .deb package, it tries to restart apache although I have apache2, so it gives an error: [ ok ] Reloading web server config: apache2. Setting up jappix (0.9.8+dfsg-1) ... invoke-rc.d: unknown initscript, /etc/init.d/apache not found. [ ok ] Reloading web server config: apache2. The postinstall script detects the presence of Apache (apache or apache2) and attemps to restart both. This could be improved and I will look into that. On my system running nginx, the script tries to restart both inexisting servers. - the font you mentioned in an earlier email - is there any reason it couldn't be listed in a separate source package in your control file? I just assumed that is might not be the best practice to generate unrelated packages from the same source. Still, it would be technically easy to do. Thank you and best regards, -- Philippe Gauthier philippe.gauth...@deuxpi.ca http://www.deuxpi.ca/ -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51e56e9f.3090...@deuxpi.ca
Bug#619347: testing the Jappix package from mentors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/07/13 18:02, Philippe Gauthier wrote: Hi Daniel, Thanks for testing the package. I am not a member of the upstream developers, but they have been very responsive to our comments so far. My testing is biased: I already had ejabberd running and I had already used BOSH to integrate with the Candy chat client so my server was able to run Jappix very quickly. It took me all of about 5 minutes to get it going. So far, I feel the Jappix chat client is more reliable for both group chat and private chat than the Candy client. The Candy client would get into a bad state after trying to start any private chat. It was very easy for me to just disable the stuff in /etc/apache2/conf.d/jappix.conf and set it up in a virtual host. In my Apache2 virtual host, I used the following to force it to work with my ejabberd: RewriteEngine On # for Candy: RewriteRule ^/example/http-bind/ http://ejabberd-host:5280/http-bind/ [P] # for Jappix: RewriteRule ^/http-bind http://ejabberd-host:5280/http-bind/ [P] I will add this line to the /etc/apache2/conf.d/jappix.conf file (possibly commented out). This is also the configuration I was using on Apache. Be careful though... it depends on mod_rewrite which may not always be enabled upstream wiki also recommends another entry in the apache conf: Header set Access-Control-Allow-Origin * That depends on mod_header, which is also not enabled be default. I'm not sure why that is needed though if everything is forced through a single domain with mod_rewrite, maybe upstream can clarify. You might need to wrap all of that in conditional config statements, e.g. IfModule mod_rewrite. and add notes about it all in README.Debian Various issues: - I feel there are a lot of options in the Jappix setup wizard. People not familiar with Jabber may not know all the server names they need to insert and the guesses are not going to be correct for a high percentage of users. This is an issue for upstream to improve. - the user login form: there should be an easy way to customize it, many people will just want the user logged in anonymously, without the full form. Candy has various login modes, in one case, it just asks the user to choose a nick name. - at one point, my Firefox test login dropped out of the chat session with Internal server error but it was happy to log in again 5 seconds later and showed the missed messages Ouch. The Debian bug tracker will probably not permit bug reports against the package yet. It should be added to the upstream bug tracker. Anonymous mode by default should not be difficult to implement and I think it would be useful. I think I might have found some stuff about this in the upstream wiki, I'll continue exploring it as well - I don't think the setup wizard should appear the first time somebody browses to the page: the admin password should be set during installation perhaps. With Drupal, it is necessary to browse to install.php to force the setup wizard to run, so random visitors don't start Drupal setup by accident. This is not highly secure either, but it removes some risk of random chance. Great idea. I will ask the Jappix developers for guidance and adapt the default configuration based on their answer. - Please add a README.Debian - if you can, include something in README.Debian about how people can integrate Jappix into their existing web site This is definitely needed. - it would be particularly interesting if you provide, under /usr/share/doc/jappix some sample ejabberd.cfg or a diff from the default Debian ejabberd.cfg - I had to enable the mod_http_bind module, declare a new domain for my anonymous web users and then declare that http_bind was permitted for that domain. I have been running Prosody for some time so I'm a bit unfamiliar with ejabberd. If you can describe the changes to the configuration, I will include them in the aforementioned README.Debian file :) Ok, I'll try and pull out a diff and send it to the ITP bug - when I installed the .deb package, it tries to restart apache although I have apache2, so it gives an error: [ ok ] Reloading web server config: apache2. Setting up jappix (0.9.8+dfsg-1) ... invoke-rc.d: unknown initscript, /etc/init.d/apache not found. [ ok ] Reloading web server config: apache2. The postinstall script detects the presence of Apache (apache or apache2) and attemps to restart both. This could be improved and I will look into that. On my system running nginx, the script tries to restart both inexisting servers. Little things like that will bother people and it undermines their first impression of the package so it is a good idea to make them run smoothly - the font you mentioned in an earlier email - is there any reason it couldn't be listed in a separate source package in your control file? I just assumed that is might not be the best practice to generate
