Re: 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.gauthier@deuxpi.ca>
http://www.deuxpi.ca/
Reply to: