[OPEN-ILS-DEV] Chop Chop

[Don McMorris]

On 6/30/07, Scott McKellar <mck9 at swbell.net> wrote:
> I've been working towards getting a working Chop Chop server on my
> machine, for development and testing.  I'm running SUSE 9.3 with
> KDE, for whatever difference that makes.
>
> Questions:
>
> 1. True or false: Chop Chop == jabber-c == osrf_chat_main.c.  I'm
> assuming true.
AFAIK, ChopChop==jabber-c, but osrf_chat_main.c is NOT part of
chop-chop (I could be wrong about this, though).

>
> 2. Is it just my imagination, or is the Wiki entry badly out of date?
That's true.  Since probably as far back as Beta-1, ChopChop wasn't
used/maintained much.  It was developed as a tool to assist in the
early development, and then virtually everything went to ejabberd.  It
actually wouldn't surprise me if ChopChop was entirely removed from
the main Open-ILS tree.

The documentation wiki ("DokuWiki") is mainly updated by volunteers.
There is less than a hand-full of full-time developers, dedicating
virtually all their work time to software development.  Historically,
development progresses so fast that the installation documentation
would need updating virtually daily.

Also, depending on the particular branch you're working from (1.0,
1.1, svn), the instructions may differ there too... There has been
work to merge configuration files.  Example: 1.0 had a bootstrap, and
openILS settings file, and a couple OpenSRF settings files.  1.1
reduced this to the bootstrap and an OpenSRF config (I'm not recalling
if there was a separate ILS config or not).  SVN "head" is working on
eliminating the bootstrap.

As a general rule, the DokuWiki tries to reflect the latest version
tarball (in this case, 1.1).  If you are trying 1.0 or HEAD, they will
likely differ.  Also, some "legacy" sections remain (such as the
ChopChop references).

>
> It says that all parameters must be specified on the command line.
> In reality the program reads a configuration file.
>
> It also says that "Chop Chop will eventually have automatic
> daemonization for process backgrounding."  Chop Chop already
> daemonizes itself.
OpenSRF was improved for these features, but installations since using
ChopChop have been minimal... As such, attention wasn't drawn to
update the instructions... Pretty much now, everyone uses ejabberd.

>
> 3. Once Chop Chop is running, is there a graceful way to bring it
> down?  It looks to me like it enters an endless loop, and the only
> way to stop it is to send it a signal with kill or the like.
There was a script in /openils/bin that controlled ChopChop.  As I
recall, it was something along the lines of 'osrf_ctl stop jserver'.

>
> 4. Once it's running, what's the simplest way to verify that it
> works?  With srfsh?  Or maybe a conventional chat client like
> Kopete or GAIM (now Pidgin)?  Do I need to have Memcached running?
For ChopChop, Telnet'ing to the port would probably be best.  You
could either simply verify the port responds, or could actually issue
Jabber commands.
`srfsh` requires OpenSRF to be up and running properly, which may not
even when ChopChop is.
I don't think ChopChop has enough functionality to support a full
client, but you could try it;) It was a strip-down minimally-compliant
server just to get a start on developing clients (IE: OpenSRF).
For ChopChop, Memcached does not need to be running.  However, for
OpenSRF needs it.

>
> Scott McKellar
> http://home.swbell.net/mck9/ct/
>
>

Summary/notes
->ChopChop is obsolete, replaced with ejabberd (a third-party product)
->It would not surprise me if ChopChop was removed from the main
source of Open-ILS (but perhaps kept to help other developers' in
other projects
->The documentation about ChopChop is outdated due to lack of use.

While here, I'll add a note about documentation...  With recent
"infrastructure" improvements, documentation should be updated faster.
 For example, a documentation volunteer may subscribe to the commit
lists and get a "heads up" on impending change  IMHO, some fairly
recent and significant changes may justify an overhaul of the
installation documentation, but this would probably be done by
volunteers due to limited amounts of (and higher priorities for) the
core developers..

--Don