[JDEV] Re:One week of running jabberd 1.4

Mon Feb 12 13:40:12 CST 2001

Again, scattered replies...

On Mon, Feb 12, 2001 at 09:20:28AM -0800, james rogers wrote:
> >> Message: 3
> >> Date: Fri, 9 Feb 2001 19:14:02 -0600
> >> From: Thomas Muldowney <temas at box5.net>
> >> To: jdev at jabber.org
> >> Subject: Re: [JDEV] One week of running jabberd 1.4
> >>
> >> Reply after each section of comments...
> >>
> >> Have you tried changing the <ip /> section in your jabber.xml? I use
> >> <ip port=3D'5225' /> for a lot of my personal testing, works great, still d=
> >> oes with final.
> >>
> 
>   Of course I tried changing the ip section of my configuration file, the pth
> module doesn't work, because it is hard coded to the jabber ports.  Look at my
> original posting to see the lines that contain the 5222 and 5269 ports.
> 

I just checked the code and usability here is the main line in question:

m = mio_listen(j_atoi(xmlnode_get_attrib(cur, "port"), 5222), xmlnode_get_data(cur), pthsock_client_listen, (void*)s__i, MIO_LISTEN_XML);

Ok, this says if in our current configuration xmlnode has a port attribute
then atoi() it and use it, otherwise default to port 5222.  The jabber.xml
<ip/> that I used inside of my <service id='c2'/> and inside the 
<pthcsock xmlns='jabber:config:pth-csock'/> was:

<ip port="5225"/>

This caused the server to work on port 5225 and not 5222, if I'm 
misunderstanding you goal, I'm sorry, and could you please inform me to it in a
different way?

> 
> >> I am the maintainer of the AIM Transport and I battled this for 3 hours and yes
> >> it is a known problem =3D) I'll have a fix put together soon for it. In the
> >> meantime you can compile it by going into the src directory and running the
> >> compilation by hand, including all the .c files as well as those in the libfaim
> >> subdirectory. I'm not going to support this method (read: don't ask me how),
> >> so unless you understand how to use the compiler fully I would suggest against
> >> trying.
> >>
> 
> I tried to compile it by hand and it blows up at the linking stage with the error
> I gave.
> 

I got this to work on a Sol7 box (I might have thrown in -lresol -lsocket and
-lnsl, I don't remember), but it still ticked me off.  So, I'm redoing my old
crufty code base (it's a burden on it's progress anyway) today and moving 
forward in the aim-t life

> >>
> >> Compilation in some cases can be a bear, and we're trying to cope with this
> >> We're working on a tool called jbox. It will know how to compile, installand
> >> configure different jabber packages. Watch for it soon.
> 
> Actually I finally used the absolute path to the jabberd directory in the yahoo
> ./configure set and it worked. Now my only problem is that the documentation hasn't
> been updated to the 1.4 version. :)
> 
> >>
> >> Have you played with the jabber.xml settings for logging? They are decent and
> >> provide a whole lot of options, although it sounds like you may need to write
> >> a quick module to do some of the updates you are looking for.
> >>
> 
> Jabberd has logging?  Will each modules give a status every X number of minutes
> telling me how many messages and the number of bytes processed since the last status
> 
> 

A module would have to be written for this level of detail.  The session log
does give number of packets in, out and session length, but that's the depth of
it.  I think this would be an excellent topic to put onto a part of the web
page that should go live soon called "The Asylum".  This will be a staging area
for ideas from people, so that we can keep track of all of these.

> >>
> >> I'm sorry but I disagree, the jabber server is distributed as a system designed
> >> to compile itself, not any random thing that people stick in it. If you are
> >> developing a new component or module for the jabber server it is not difficult
> >> to add it in to the build system, or have your own external build system. Again,
> >> jbox will help solve some of these problems.
> 
> I am vaguely offended by your comment.  I am not sticking random things in the
> directory, I am placing an authentication module that authenticates users against
> a global registration system with several million entries using xml over http.  It
> will make my life easier to simply place the module into the directory and have it
> compile rather than have to edit two different make files each in a different directory
> everytime I upgrade to a new project.  It is certainly not difficult, but it is somewhat
> annoying, especially when it is trivial to fix the problem.
> 
> And what happens when I have 50 extra modules that different people have written that
> I want to include, certainly you aren't even recommending that I hand edit two different
> make files with 50 different entries every time jabber.org comes out with a new release?
> 

I'm sorry that I upset you, it was never my intention.  I did the entire build
system by hand, and I hate it.  I wish I had more time to more solidly put 
together a strong automake system, but that was going to prove a burden in many
of the spots that we needed, so I did it by hand, and overly rapidly.  I never
even really intended for it to last this long.  We decided to develop jbox in
hopes that it can alleviate that exact problem that you are having.  Again,
this is a high priority of mine, and it should have a release soon (jabber-1.4
already should have the hooks for jbox, although I'm not sure if it was
distributed with them).

> >>
> >> It sounds like you want to be using xdb. Look at the xdb_get and xdb_set
> >> functions.
> 
> No, if you add a new section to the jabber config file the system won't start because it
> complains about the configuration file being wrong.  I can modify the configo function to
> handle this, but I find doing this to be kinda annoying.  Ideally it would simply parse
> unknown sections for retrieval by another module later.
> 

I went back and read your question again, I'm sorry I misunderstood.  I'm not
sure about the ability to hook into the config yet as a top level tag in the 
config, but inside a service it is very possible to add in configuration 
elements, and this tends to cover a lot of cases.  Could you expand on what your
needs are?

> >>
> >> It would seem that a lot of your problems come due to poor documentation.
> >> That's always been a hard issue for us, as many of the developers do some of the
> >> documentation, but we find ourselves spending most of our time on the core
> >> system. As soon as the new website backend goes live (one of my current top
> >> priorities) I plan to spend significant time doing documentation. Expect
> >> status reports to the list.
> >>
> >> --temas
> 
> Thanks, good documentation would be appreciated.
> 
> 

Hopefully we cleared a bit more up this time.  I'll see if I can get a version
of jbox released, I would _love_ to have you and others as beta testers of it,
as we want it to be very powerful.  Thank you for your patience, and again, I'm
sorry if I offended you in anyway, at any time.

--temas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20010212/95d68a84/attachment-0002.pgp>