pygcs-devel Mailing List for PyGCS

My server has been running the new asynchat-based network code for
quite a while with zero crashes.  If we can get some testing on
another server or two, it may be time to roll out a new release.

-Justin

 

I have changed lib/cmdclass.py and lib/text/help/wb_erase to
use 'wb_erase mine' (the way Justin originally had it) instead
of 'wb_erase all' to delete all owned whiteboard messages.

The command 'wb_erase' with no args, run by the admin, will erase
the whole whiteboard.  Normal users will be told that wb_erase
requires an argument.

I have also put a date-string in lib/version.py and updated the
version number to be '1.5.0'.  So, whoever can, please beat on
this code in the next few days if you can get around to it.
I've been running the code (not the new changes I added just
now) with 5 or 6 active daily users and it all seems fine, but...

So, things that are new and need testing the most:

- who and finger now allow args
- wb_erase <arg>
- wb_write <arg>
- quit <message> and persistence across server restarts/crashes/kills
- whiteboard persistence across server restarts/crashes/kills

I plan to release 1.5.0 on Wednesday night or so.

> So, what with all of these fancy new features, it might be approaching 
> time for a release, eh?  Once it's had a bit more testing, of course.

Yeah, with more testing for sure.  The whiteboard seems pretty much
fine though.

> I'm not sure if 1.4.1 or 1.5.0 would be more appropriate, since I
> don't yet know what the third part of the version number signifies in PyGCS.

I'm thinking 1.5.

> I haven't touched the wb_erase stuff since our latest discussion.
> Perhaps later today; I don't know.  Does the log rotation stuff look
> okay to you?

Barring the wb_erase stuff, let's consider ourselves in a feature freeze
as of now.

I've had zero time to look at anything in a week, and I might not
for another few days.  The stuff I am running is dated 7/10.

So, what with all of these fancy new features, it might be approaching 
time for a release, eh?  Once it's had a bit more testing, of course.

I'm not sure if 1.4.1 or 1.5.0 would be more appropriate, since I
don't yet know what the third part of the version number signifies in PyGCS.

I haven't touched the wb_erase stuff since our latest discussion.
Perhaps later today; I don't know.  Does the log rotation stuff look
okay to you?

-Justin

 

> > > Yeah, we were thinking quite differently about those.  I personally
> > > think that 'wb_erase mine' makes more sense for the above command than 
> > > 'wb_erase all' does.  Its meaning is clearly just what it says.  But I 
> > > will defer to your judgement here.
> > 
> > The more I think about it, 'mine' does seem right even if it is a bit
> > misleading if thought of certain ways.
> 
> So what is the end result here?  Which way do we want it to work?

Go back to 'mine' :)

Done and committed.

Old logs are now rolled to:

<logfilename>.YYYYMMDDHHMMSS

-Justin

 

Jeff Blaine <jef...@me...> writes:

> > Yeah, we were thinking quite differently about those.  I personally
> > think that 'wb_erase mine' makes more sense for the above command than 
> > 'wb_erase all' does.  Its meaning is clearly just what it says.  But I 
> > will defer to your judgement here.
> 
> The more I think about it, 'mine' does seem right even if it is a bit
> misleading if thought of certain ways.

So what is the end result here?  Which way do we want it to work?

-Justin

 

> Yeah, we were thinking quite differently about those.  I personally
> think that 'wb_erase mine' makes more sense for the above command than 
> 'wb_erase all' does.  Its meaning is clearly just what it says.  But I 
> will defer to your judgement here.

The more I think about it, 'mine' does seem right even if it is a bit
misleading if thought of certain ways.

Jeff Blaine <jef...@me...> writes:

> So, it finally hit me what you really were speaking about, and I hope you
> didn't put much effort into changing it yet.

Well, I thought I sent you mail after I committed the change.  No
matter, though, it was a three-line change and I can back it out
pretty easily.

> The way I had it set up was:
> 
>   - 'wb_erase all' should erase all of the calling user's messages, even the
>     admin.  I made a comment in the CVS log when I committed it that the
>     reason I didn't like 'wb_erase mine' was because it made it seem like
>     there was another option available (e.g. wb_erase otherpeoples).  But
>     I guess the point I really wanted to make here was that I don't think
>     'wb_erase all' should act differently for Admin.  There could certainly
>     be a need for Admin to want to erase all of his/her messages only.
> 
>   - wb_erase (with no args) works only as admin, and erases the whole 
>     whiteboard

Ohhhh.

Yeah, we were thinking quite differently about those.  I personally
think that 'wb_erase mine' makes more sense for the above command than 
'wb_erase all' does.  Its meaning is clearly just what it says.  But I 
will defer to your judgement here.

I'll back out my changes later today and make sure that things match
this model when I'm done.

-Justin

 

So, it finally hit me what you really were speaking about, and I hope you
didn't put much effort into changing it yet.

The way I had it set up was:

  - 'wb_erase all' should erase all of the calling user's messages, even the
    admin.  I made a comment in the CVS log when I committed it that the
    reason I didn't like 'wb_erase mine' was because it made it seem like
    there was another option available (e.g. wb_erase otherpeoples).  But
    I guess the point I really wanted to make here was that I don't think
    'wb_erase all' should act differently for Admin.  There could certainly
    be a need for Admin to want to erase all of his/her messages only.

  - wb_erase (with no args) works only as admin, and erases the whole 
    whiteboard

If there are ways to make that better, please comment.

Jeff Blaine <jef...@me...> writes:

> I vote for 1, with the caveat that the suffix or prefix is
> YYYYMMDDHHMMSS.

I was thinking that it would be something like that, yes.

Okay.  I'll do that sometime soon.

-Justin

 

I vote for 1, with the caveat that the suffix or prefix is
YYYYMMDDHHMMSS.

But yes, 2 would be more in line with standard daemons.  I tend not
to think of a chat server as a standard daemon I guess.

> Right now, when one restarts a PyGCS server, the previous log file
> is just destroyed, since the server just does an open(fn, 'w') on the
> filename.
> 
> I suggest one of the following:
> 
> 1) When the server starts, if a file that would be overidden exists, move
>    it out of the way with a meaningful suffix attached.
> 
> 2) Append to the file instead of overwriting.
> 
> I would be more than willing to write the code for either, I just want to
> see which method you prefer.  My guess is choice 2, which would then
> also allow someone that really wanted to to also use a 3rd party utility
> to rotate the grwoing logs out of the way so that they didn't get too
> enormous.

I submitted this on sourceforge, but I don't know if any notification
comes out of that, so I thought I'd mention it here too.

Right now, when one restarts a PyGCS server, the previous log file
is just destroyed, since the server just does an open(fn, 'w') on the
filename.

I suggest one of the following:

1) When the server starts, if a file that would be overidden exists, move
   it out of the way with a meaningful suffix attached.

2) Append to the file instead of overwriting.

I would be more than willing to write the code for either, I just want to
see which method you prefer.  My guess is choice 2, which would then
also allow someone that really wanted to to also use a 3rd party utility
to rotate the grwoing logs out of the way so that they didn't get too
enormous.

Thoughts?

-Justin

 

Justin Sheehy <dw...@cc...> writes:

> Since I can't do it just this second, I registered a bug and assigned
> it to myself.  I expect to fix in within the next day or so.

I lied.  I was able to do it right away.  Done.

-Justin

 

Jeff Blaine <jef...@me...> writes:

> > Hm.  At first look, it looks like you made 'erase all' into 'erase mine'.
> 
> Other way around.  I turned wb_erase mine into wb_erase all.

Heh.  A matter of perspective, I guess.  I meant that you made
'wb_erase all' do what 'wb_erase mine' used to do.  In the end, same
result, just a different way of looking at it.

> > If Admin does a wb_erase, it does the right thing.  If Admin does a
> > 'wb_erase all', it only erases messages from Admin.
> > 
> > Want me to fix, or you?  It should be a trivial fix.
> 
> Go for it

Will do.

Since I can't do it just this second, I registered a bug and assigned
it to myself.  I expect to fix in within the next day or so.

-Justin

 

> > Added ownership of whiteboard items per Klaus since we had gone
> > that far already.  Admin can erase all or any selected messages.
> > Normal users can only erase selected messages of theirs or 'wb_erase
> > all' which will erase all of theirs.  I didn't like the keyword
> > 'mine' anymore since that implies that there is a way for normal
> > users to erase other peoples'.
> 
> Given the way I structured the Whiteboard, that ought to have been
> easy, eh?  (Since the username is already tied to the message...)

Yep

> Btw, do you like the way that class was done?  Feedback is welcome,
> especially if you think it ought to change in some way.

Seems fine to me.  My only hesitation was (and it has nothing to do with
how your class was written or structured) where to embed the ownership
restriction for wb_erase and the Admin-can-override stuff.

> Hm.  At first look, it looks like you made 'erase all' into 'erase mine'.

Other way around.  I turned wb_erase mine into wb_erase all.

> If Admin does a wb_erase, it does the right thing.  If Admin does a
> 'wb_erase all', it only erases messages from Admin.
> 
> Want me to fix, or you?  It should be a trivial fix.

Go for it

bin/defines.py
    Added max_wb_line_length (default of 256), changed wb_user_max to 5
    as a default

lib/cmdclass.py
    Added support for defines.max_wb_line_length in UserCMD_wb_write

Jeff Blaine <jb...@sh...> writes:

> Added ownership of whiteboard items per Klaus since we had gone
> that far already.  Admin can erase all or any selected messages.
> Normal users can only erase selected messages of theirs or 'wb_erase
> all' which will erase all of theirs.  I didn't like the keyword
> 'mine' anymore since that implies that there is a way for normal
> users to erase other peoples'.

Given the way I structured the Whiteboard, that ought to have been
easy, eh?  (Since the username is already tied to the message...)

Btw, do you like the way that class was done?  Feedback is welcome,
especially if you think it ought to change in some way.

Hm.  At first look, it looks like you made 'erase all' into 'erase mine'.

If Admin does a wb_erase, it does the right thing.  If Admin does a
'wb_erase all', it only erases messages from Admin.

Want me to fix, or you?  It should be a trivial fix.

-Justin

 

Added ownership of whiteboard items per Klaus since we had gone
that far already.  Admin can erase all or any selected messages.
Normal users can only erase selected messages of theirs or 'wb_erase
all' which will erase all of theirs.  I didn't like the keyword
'mine' anymore since that implies that there is a way for normal
users to erase other peoples'.

"Jeff Blaine" <jef...@me...> writes:

> The more I think about it, I would definitely do it per-user unless there's
> a good reason that's not doable, and I would just not allow any new messages
> and tell the user to clean up his/her shit :)

Done and committed.  Default is max of 20 per user.

Test and enjoy.

-Justin

 

"Jeff Blaine" <jef...@me...> writes:

> The more I think about it, I would definitely do it per-user unless there's
> a good reason that's not doable, and I would just not allow any new messages
> and tell the user to clean up his/her shit :)

Definitely doable.  It'll be a little performance hit at
wb_write-time, but not too bad unless the whiteboard gets really big.

I will do that tomorrow.  What do you want the per-user default to be?

> Thanks for the code, BTW, it rocks.  Now _that's_ a proper whiteboard.

Happy to be of service.

Heading out for dinner and a concert now.

-Justin

 

> > - It's probably a good idea for us to have an admin-configurable
> >   max_wb_messages in defines.py and wb_write and others doing the
> >   right thing based on that.  Maybe max_wb_messages_per_user ?
> >   Something.  Comments?
>
> Good idea.  However, what should be the behavior when these limits are
> exceeded?  Erase messages off of the front, not allow any new messages
> until some are deleted, or something else?

The more I think about it, I would definitely do it per-user unless there's
a good reason that's not doable, and I would just not allow any new messages
and tell the user to clean up his/her shit :)

Thanks for the code, BTW, it rocks.  Now _that's_ a proper whiteboard.

Justin Sheehy <dw...@cc...> writes:

> > - I wrote 2 things on the whiteboard, deleted item 2, booted
> >   everyone, and then killed the server via kill from a shell.
> >   When I started the server back up, both were on the
> >   whiteboard.
> 
> Ah.  My bad.  I'll fix this.

I'm about to run out for a few hours, but I checked in a quick fix
that ought to take care of this problem.  See if the problem is gone.
If not, just say so, and I'll deal with it tonight or tomorrow.

-Justin

 

"Jeff Blaine" <jef...@me...> writes:

> - It's probably a good idea for us to have an admin-configurable
>   max_wb_messages in defines.py and wb_write and others doing the
>   right thing based on that.  Maybe max_wb_messages_per_user ?
>   Something.  Comments?

Good idea.  However, what should be the behavior when these limits are 
exceeded?  Erase messages off of the front, not allow any new messages
until some are deleted, or something else?

> - I wrote 2 things on the whiteboard, deleted item 2, booted
>   everyone, and then killed the server via kill from a shell.
>   When I started the server back up, both were on the
>   whiteboard.

Ah.  My bad.  I'll fix this.

-Justin

 

In playing around with it, I found 2 things

- It's probably a good idea for us to have an admin-configurable
  max_wb_messages in defines.py and wb_write and others doing the
  right thing based on that.  Maybe max_wb_messages_per_user ?
  Something.  Comments?

- I wrote 2 things on the whiteboard, deleted item 2, booted
  everyone, and then killed the server via kill from a shell.
  When I started the server back up, both were on the
  whiteboard.