Actually, those generalized notification methods have been on the
to-do list for a long time. A bunch of faculty who don't want to
check their CoWeb, but do want to know where there are changes, have
asked for weekly/daily digests.
Mark
>>From: [EMAIL PROTECTED]
>>Date: Tue, 27 Mar 2001 12:12:10 -0500 (EST)
>>To: [EMAIL PROTECTED]
>>Subject: BOUNCE [EMAIL PROTECTED]: Non-member submission from
>>[[EMAIL PROTECTED]]
>>
>> >From [EMAIL PROTECTED] Tue Mar 27 12:12:07 2001
>>Received: from smtpsrv0.isis.unc.edu (smtpsrv0.isis.unc.edu [152.2.1.139])
>> by burdell.cc.gatech.edu (8.9.1/8.9.3) with ESMTP id MAA14130
>> for <[EMAIL PROTECTED]>; Tue, 27 Mar 2001 12:12:06 -0500 (EST)
>>From: [EMAIL PROTECTED]
>>Received: from JANEG-PC2 ([152.2.81.69])
>> by smtpsrv0.isis.unc.edu (8.9.3/8.9.1) with ESMTP id MAA14864
>> for <[EMAIL PROTECTED]>; Tue, 27 Mar 2001 12:11:56 -0500 (EST)
>>Date: Tue, 27 Mar 2001 12:16:00 -0500
>>To: [EMAIL PROTECTED]
>>Subject: Re: [pws] Correction!
>>Message-ID: <2147849854.985695360@JANEG-PC2>
>>In-Reply-To: <[EMAIL PROTECTED]>
>>X-Mailer: Mulberry/2.0.5 (Win32)
>>MIME-Version: 1.0
>>Content-Type: text/plain; charset=us-ascii; format=flowed
>>Content-Transfer-Encoding: 7bit
>>Content-Disposition: inline
>>
>>--On Tuesday, March 27, 2001 10:37 AM -0500 "Jochen F. Rick"
>><[EMAIL PROTECTED]> wrote:
>>
>> > Yeah Bijan!!!
>> >
>> > The stripped version seems not to be too good a thing in all. I had to
>> > correct it several times. I think I'll stick with barely minimized for
>> > release 1.
>>
>>I'm going to do some more investigation on stripping in general (er...not
>>the way that sounds!) Losing many of the file in capacities is just a bad
>>idea, IMHO.
>>
>>OTOH, I was never very fond of the particular SMTPSocket class
>>method....you could have trouble down the road if a lot of notifications go
>>out one after the other (I'm pretty sure...I seem to recall that if you
>>have a lot of sends in short order, they recommend setting up one socket
>>and reusing it). Some sort of flyweight pattern might help there.
>>
>> >From the method comment:
>>
>> "Deliver a single email to a list of users and then close the
>>connection.
>> For delivering multiple messages, it is best to create a
>>single connection
>> and send all mail over it. NOTE: the recipient list should be
>>a collection
>> of simple internet style addresses -- no '<>' or '()' stuff"
>>
>>I'll attest that I've run into trouble with this, with fairly light traffic.
>>
>>It shouldn't be hard at all to put a little time outer on a cached socket,
>>and check for it being open in an extended #mailFrom:to:text: Or we could
>>cache messages until a timeout or a certain number accumulate before
>>sending in a batch.
>>
>>In the end that's likely to be more reliable and scalable.
>>
>>Also, it would be *really* nice to not have a notification for *each* page
>>change. Often when I'm editing, I'll save early and often (a wise
>>precaution in this continual age of crappy, crash prone browsers). The
>>flood of edit notices is a bit of a pain. (Hmm. even better would be a
>>"save and keep editing" button on the edit page...good idea in general.)
>>
>>So a time delay of an hour or so between notification triggering would be
>>grand.
>>
>>Ooo, while I'm at it (and this should be easy) a notification digest would
>>be cool. I.e., once a day, if any pages were changed, I could get something
>>like:
>>
>> Changes for 2001-03-26 on the Squeak Swiki:
>> Page Comanche saved 5 times by bob
>> 6 times by mary
>> Page Newbie Tips (or the url) saved....
>>etc.
>>
>>The detailed view may not need to be the only one...i.e., some folks might
>>just want the fact that they've changed.
>>
>>Ooo, while I'm brainstorming, it'd be nice to be able to manage all the
>>pages set to notify me in one place. So:
>>
>> Notifications to [EMAIL PROTECTED]:
>>
>> <textarea>Comanche
>>Newie Tips
>>Bijan Parsia
>>The Top Page
>></textarea>
>>
>>--------
>>
>>Again, an option for immediate or digest mode would rule.
>>
>>Cheers,
>>Bijan.
>
>--------------------------
>Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
>Associate Professor - Learning Sciences & Technologies.
>Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/
>(404) 894-5618 : Fax (404) 894-0673 : [EMAIL PROTECTED]
>http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
--------------------------
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
Associate Professor - Learning Sciences & Technologies.
Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/
(404) 894-5618 : Fax (404) 894-0673 : [EMAIL PROTECTED]
http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html