Hi fellow Celestians,

When fetching my mail I got a debugger because Celeste cannot parse a
certain message using MailMessage.from:. See the script below to recreate
the walkback. I am not sure whether this is a bug in Celeste or the message
string is not valid. I would appreciate any tips on how to best deal with
this situation.

However, I think the current handling of incorrect messages could be
improved. If Celeste encounters a message it cannot parse it just opens a
debugger and stops downloading. It does not continue downloading the other
messages. Even worse, it does not delete the already downloaded messages so
that if I fetch mail again it downloads them a second time. In my case these
are 1500 :-(. (I often wondered if there is a reason why Celeste first
downloads all the messages and then removed all of them from the server
instead of fetching and deleting them one by one.)

Of course the question is, what should we do with invalid messages? Just
throw them away seems not be the best solution. Perhaps they could be filed
using special IndexFileEntries so that they can be found and dealt with
later?

So, what do you think?

- Bernhard

MailMessage from: 'Return-path: <vwnc-request at cs.uiuc.edu>
Envelope-to: bernhard at pieber.com
Delivery-date: Tue, 06 Nov 2001 23:05:57 +0100
Received: from jerry.cs.uiuc.edu ([128.174.246.71])
 by mx.inode.at with smtp (Exim 3.31 #2)
 id 161EM0-0001ut-00
 for bernhard at pieber.com; Tue, 06 Nov 2001 23:05:56 +0100
Received: (qmail 7549 invoked by uid 510); 6 Nov 2001 22:02:03 -0000
Resent-Date: 6 Nov 2001 22:02:03 -0000
Resent-Cc: recipient list not shown: ;
Reply-To: stingray at paradise.net.nz
To: "vwnc at cs.uiuc.edu" <vwnc at cs.uiuc.edu>
Subject: Fix of Timestamp>>fromDate:andTime:
Date: Wed, 7 Nov 2001 10:57:36 +1300
X-Mailer: KMail [version 1.0.29.2]
Content-Type: Multipart/Mixed;
  boundary="Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD"
MIME-Version: 1.0
Message-Id: <01110710580401.01051 at localhost.localdomain>
Content-Transfer-Encoding: quoted-printable
From: Stewart MacLean <stingray at paradise.net.nz>
Resent-Message-ID: <pPCHSC.A.j1B.a3F67 at jerry.cs.uiuc.edu>
Resent-From: vwnc at cs.uiuc.edu
X-Mailing-List: <vwnc at cs.uiuc.edu> archive/latest/5962
X-Loop: vwnc at cs.uiuc.edu
Precedence: list
Resent-Sender: vwnc-request at cs.uiuc.edu


--Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


''From VisualWorks=AE, Release 3.1 of 19 March 1999 on 7 November 2001 at =
11:02:18 am''!
This method (VW3.1) assumes that when creating a Timestamp that time is l=
ess
than 24 hours. As Time can be of a longer duration than this, the date ne=
eds to
be rolled over when time is equal or greater than 24 hours.

Cheers,

Stewart


!Timestamp methodsFor: ''BASE''!

fromDate: date andTime: time

=09"Set receiver from the date and time.
=0906/11/2001 SIM Rollover the date by the number of integral days in tim=
e.
=09This removes the assumtion that time is less than 24 hours duration."

=09date isNil
=09=09ifTrue: [year :=3D 0. month :=3D day :=3D 1]
=09=09ifFalse: [self fromDate: date].
=09time isNil
=09=09ifTrue: [hour :=3D minute :=3D second :=3D millisecond :=3D 0]
=09=09ifFalse:=20
=09=09=09[hour :=3D time hours.
=09=09=09day :=3D day + (hour // 24).
=09=09=09hour :=3D hour \\ 24.
=09=09=09minute :=3D time minutes.
=09=09=09second :=3D time seconds.
=09=09=09millisecond :=3D 0]! !
--Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD
Content-Type: text/english;
  name="Timestamp-fromDateandTime.st"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Timestamp-fromDateandTime.st"

J0Zyb20gVmlzdWFsV29ya3OuLCBSZWxlYXNlIDMuMSBvZiAxOSBNYXJjaCAxOTk5IG9uIDcgTm92
ZW1iZXIgMjAwMSBhdCAxMTowMjoxOCBhbSchCgoKCiFUaW1lc3RhbXAgbWV0aG9kc0ZvcjogJ0JB
U0UnIQoKZnJvbURhdGU6IGRhdGUgYW5kVGltZTogdGltZQoKCSJTZXQgcmVjZWl2ZXIgZnJvbSB0
aGUgZGF0ZSBhbmQgdGltZS4KCTA2LzExLzIwMDEgU0lNIFJvbGxvdmVyIHRoZSBkYXRlIGJ5IHRo
ZSBudW1iZXIgb2YgaW50ZWdyYWwgZGF5cyBpbiB0aW1lLgoJVGhpcyByZW1vdmVzIHRoZSBhc3N1

bXRpb24gdGhhdCB0aW1lIGlzIGxlc3MgdGhhbiAyNCBob3VycyBkdXJhdGlvbi4iCgoJZGF0ZSBp
c05pbAoJCWlmVHJ1ZTogW3llYXIgOj0gMC4gbW9udGggOj0gZGF5IDo9IDFdCgkJaWZGYWxzZTog
W3NlbGYgZnJvbURhdGU6IGRhdGVdLgoJdGltZSBpc05pbAoJCWlmVHJ1ZTogW2hvdXIgOj0gbWlu
dXRlIDo9IHNlY29uZCA6PSBtaWxsaXNlY29uZCA6PSAwXQoJCWlmRmFsc2U6IAoJCQlbaG91ciA6
PSB0aW1lIGhvdXJzLgoJCQlkYXkgOj0gZGF5ICsgKGhvdXIgLy8gMjQpLgoJCQlob3VyIDo9IGhv
dXIgXFwgMjQuCgkJCW1pbnV0ZSA6PSB0aW1lIG1pbnV0ZXMuCgkJCXNlY29uZCA6PSB0aW1lIHNl
Y29uZHMuCgkJCW1pbGxpc2Vjb25kIDo9IDBdISAhCg==

--Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD--



'