On 10/7/06, Daniel <[EMAIL PROTECTED]> wrote:
> On Oct 7, 2006, at 12:21 PM, Norman Rasmussen wrote:
> > mmm, can you go back to an older version and see if it has the issues
> > (you can ask cvs to check out from a specific date)
>
> I didn't have a problem before I switched from the released version,
> I don't think.  Any recommendation on which date I should choose?

The release was done 2006-03-07, so anytime after that :-P  You can
see a list of history here:
http://xmpppy.cvs.sourceforge.net/xmpppy/xmpppy/yahoo-transport/yahoo.py?view=log
so my thoughts are try and figure out which bunch of checkins is
causing the bug (by a process of elimination)

(moved this up for disco comments)
> >> This is incredibly
> >> annoying, as I can't re-register with the client I normally use
> >> (mcabber), and have to instead load up Psi to do it.  Any ideas?
> >
> > I hear you.  Heh, swap to Psi :-P
>
> I can't use Psi from work, I can only use a console client.  I really
> like mcabber, and I know the developer is probably going to work on
> getting disco support at some point in time, but until then... :)

Pity.  Disco is really cool.  Adhoc is really cool too.

> > > I get it all set
> > > up, everything is running well for the most part, though I do get
> > > frequent disconnections.
> >
> > These are from the Yahoo server right?  How many users do you have
> > using your server?  (I've found that if I 'force connect' my 7 or 8
> > users when I restart the transport, that some of the logins fail - I
> > assume due to some Yahoo rate limiting)
>
> I usually only have a handful of users on my server (maybe 5-6), but
> I have no idea how many users are using the Yahoo transport.  Since
> it allows registration from outside my server, it may be quite a
> few.  Do you know of a way to tell?

via Disco, or Adhoc :-)  both will give you a list of registered
users, and a list of connected users - if you're listed in the admins
section.  (Try Psi from home to see what I mean)

> But yes, it seems that Yahoo
> disconnects me frequently.  This is another problem that seemed to
> become worse with the CVS version.

Yea, the trouble is: is this the transport getting less stable, or
Yahoo's server getting less stable :-P

> I've had a few times where it simply died by itself,
I've been trying to fix those (mostly fixed).  The other day python
segfaulted, which unfortunatly there's nothing I can do to fix that.

> but occasionally
> I'll kill it if I need to reboot the machine or restart the Jabber
> server, and then I'm just killing the process with kill.

Standard kill (TERM), should do a graceful shutdown, and notify all
users that the transport is now offline, it should cleanly close all
files, etc.

> > > When I
> > > connect after restarting the process, the transport and all my Yahoo
> > > contacts have revoked authorization, and any attempts to send
> > > messages to the transport or to my Yahoo contacts has the transport
> > > telling me that I'm not registered with it.
> >
> > :-( this should not happen.  Are other users also loosing their
> > registrations?  The userfile is synced to disk as soon as it's
> > updated.  Is the file possibly becoming corrupted? Which version of
> > python are you using (and bdb/bsddb if you can tell)
>
> I don't know if it's happening to any others.  I haven't received any
> complaints about it, but I would assume if it's happening to me it's
> happening to others as well.

sounds about right, and then they don't try and report the bug either :-P

> I'm using Python 2.4.3.
I've been using 2.3.5, and 2.4.4c0

> As far as bdb,
> do you mean Berkeley DB?  I think I'm using version 4.1.25.  That's
> what's installed from ports anyway (this is a FreeBSD 6.1 machine).

Actually I think the transport is using pickle for it's database, not
bsddb - so this point is moot.  What does:

$ python
>>> import shelve
>>> shelve.Pickler.__module__
>>> shelve.StringIO.__module__

show?

> Interestingly enough, and I don't know if this matters or not, but if
> I run strings on yahoouser.dbm.db and grep for my Yahoo username, I
> get 51 matches.  I don't have 51 Yahoo people in my roster, however.

There seems to be a lot of rubbish data in my user file, so maybe
that's what you're finding in the strings.  Also you have to consider
your yid on other users rosters.

You can convert the user file into an html format using:
http://www.darkskies.za.net/~norman/jabber/yahoo-transport/yuser_html.tar.gz
 which will make it a lot easier to see what's going on.

-- 
- Norman Rasmussen
 - Email: [EMAIL PROTECTED]
 - Home page: http://norman.rasmussen.co.za/
From [EMAIL PROTECTED]  Sun Oct  8 13:55:14 2006
From: [EMAIL PROTECTED] (Norman Rasmussen)
Date: Sun Oct  8 13:55:20 2006
Subject: [py-transports] PyYIMt avatars
Message-ID: <[EMAIL PROTECTED]>

I'm interested in what people's thoughts are on the following:

Currently the PyYIMt subscription data is stored (all in one file) like this:

  [EMAIL PROTECTED]:
    userrname: yuser1
    password: ypassword1
    subscribed: true
    avatar:
      yusera: (sha1hash, avatarimagedata)
      yuserb: (sha1hash, avatarimagedata)
      yuserc: (sha1hash, avatarimagedata)
  [EMAIL PROTECTED]:
    userrname: yuser2
    password: ypassword2
    subscribed: true
    avatar:
      yuserc: (sha1hash, avatarimagedata)
      yuserd: (sha1hash, avatarimagedata)
      yusere: (sha1hash, avatarimagedata)

Now obviously this means that the single file gets fairly big with all
the avatars, and that if multiple transport users have the same
contacts, or if multiple contacts have the same avatar, then that data
is stored multiple times.

Does it make sense to extract the avatar out of the data file, and
store it like the other transports?  If so, does it get stored like
pymsnt (newer - global for the whole transport), or pyaimt/pyictq
(older - set of avatars per copy of transport).  I think that storing
the avatars on the filesystem as individual files is a bonus, because
then the admin can use standard tools to archive old/unused data.

What are people's thoughts on converting the entire file to the file
system based format (xml files in sha1'ed folders) - btw: this is a
lot more work than just extracting the avatar image data :-P

-- 
- Norman Rasmussen
 - Email: [EMAIL PROTECTED]
 - Home page: http://norman.rasmussen.co.za/
From [EMAIL PROTECTED]  Sun Oct  8 14:36:52 2006
From: [EMAIL PROTECTED] (Brian Safford)
Date: Sun Oct  8 14:37:06 2006
Subject: [py-transports] PyYIMt avatars
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

Please keep large implementations in mind while engineering this ...
once I can get PyYIMt patched to work with Jabber XCP, I have about
12,000 users (3,000 concurrent) to throw at it ...

Thanks,
Brian Safford
EDS

On Sun, 2006-10-08 at 15:55 +0200, Norman Rasmussen wrote:
> I'm interested in what people's thoughts are on the following:
> 
> Currently the PyYIMt subscription data is stored (all in one file) like this:
> 
>   [EMAIL PROTECTED]:
>     userrname: yuser1
>     password: ypassword1
>     subscribed: true
>     avatar:
>       yusera: (sha1hash, avatarimagedata)
>       yuserb: (sha1hash, avatarimagedata)
>       yuserc: (sha1hash, avatarimagedata)
>   [EMAIL PROTECTED]:
>     userrname: yuser2
>     password: ypassword2
>     subscribed: true
>     avatar:
>       yuserc: (sha1hash, avatarimagedata)
>       yuserd: (sha1hash, avatarimagedata)
>       yusere: (sha1hash, avatarimagedata)
> 
> Now obviously this means that the single file gets fairly big with all
> the avatars, and that if multiple transport users have the same
> contacts, or if multiple contacts have the same avatar, then that data
> is stored multiple times.
> 
> Does it make sense to extract the avatar out of the data file, and
> store it like the other transports?  If so, does it get stored like
> pymsnt (newer - global for the whole transport), or pyaimt/pyictq
> (older - set of avatars per copy of transport).  I think that storing
> the avatars on the filesystem as individual files is a bonus, because
> then the admin can use standard tools to archive old/unused data.
> 
> What are people's thoughts on converting the entire file to the file
> system based format (xml files in sha1'ed folders) - btw: this is a
> lot more work than just extracting the avatar image data :-P
> 

Reply via email to