Penny Post

Fixed by version 1.4.
Please upgrade your version. Tx.

Hi Ali,

Aha! I should have recognised that really (I'm an Enterprise IT Architect)
- caching of various sorts is within my field of understanding (whereas
actual coding isn't!), so I really ought to have worked that one out!
Certainly makes perfect sense.

Glad to be of assistance, and I look forward to the modified version so
that I can delete my machine-specific (no doubt) kludge.

SoV

hi Sov,
If the fileSize is zero to start with I think I know whats happening.
Its called file write caching. When the first call to write to file is
made, windows does not write the value immediately, but keeps it in a tiny
buffer to write the whole buffer in one shot. so the next call still finds
the size zero. No doubt the difference is very small - 2 milliseconds. Then
windows realizes nothing is happening to the file, so it completes the
write and closes the file (modifying the mod time)

So the issue can be solved by reading the file mod time at a later stage.
I'll send you the modified file later. In the meantime your -2 fix should
keep things going.

Many thanks for the effort on this. It is much appreciated.

--Ali

Hi Ali,

That all makes sense. I can't see how to find out whether anything is
modifying the file.Modifiedtime, so I've given up on that option (I tried
running with everything but background processes off and still had the
problem). As you say, it's not a solution.

I have tried the file.fileSize technique, which suffers in a similar
manner. Specifically (putting two alerts in the script to show the
file.fileSize and the iModtime (redefined) parameter, I see the former as
'0' and the latter as '41', consistently, if I see both alerts before the
java console closes. i.e. as with the time technique, there is a consistent
'error' in that the file.fileSize is not initially what could be expected.
It looks as if the call to find that is happening slightly before the
java.exe is called, and hence both time and file size are wrong.

I'm happy to stick with my minus 2 version, which works for me, until you
have a version which successfully uses file size!

I hope this has been of some help in developing the extension.

SoV

Hi Sov,

Reading your first post today: iLastMod is passed into the function
readBack from the calling function. This value is originally recorded in
readFromProgram() near the comment
//save last mod time

If you see the file object is not touched after the value is recorded
except for the line file.path.
So I would suggest you swap the order of the two lines (as the order is
not important here) as follows:
//save filepath
var sFilePath = file.path;
//save last mod time
var iLastMod=file.lastModifiedTime;

iLastMod is then passed (handed) on to called functions.

Now, giving some thought to what you say is happening, I'm quite sure that
changing the order of the lines above will NOT fix the original problem.
But give it a try nevertheless.
(remember to remove your -2 fix before testing the swap)

I think after the file is created, some other process on your system is
changing its modification time, before pennypost console.
What process do you think on your system would be interested in files
created on disk (a virus scanner or a backup tool maybe?)

NOTE: by doing the -2 you are compensating for the time and this fix may
not work for everyone.
-----
As far as I'm concerned, I realize that my technique of detecting file
modification change is not working on all systems as the mod time is
changable even without actually modifying the file. Any process can change
it by requesting the OS to mark the file as modified.

A better technique would be to use the file size as a modification
detector.
The file size will change only when something (bigger) is actually written
into the file.
So I will make changes so that the next version uses the file size instead
of mod time.

Best regards,
Ali

PS: You can try this change too if you like. You will need to replace
calls to file.lastModifiedTime with a call to file.fileSize in both
readback and readFromProgram
for e.g.:
"file.lastModifiedTime !=iLastMod" becomes "file.fileSize !=iLastMod"
and "var iLastMod=file.lastModifiedTime;" becomes "var
iLastMod=file.fileSize;"


FYI: the file object is supplied by Mozilla architecture. The entire set
of properties available from the file object can be found here
http://www.xulplanet.com/references/xpcomref/ifaces/nsIFile.html

Hi Ali,

Some success!

I was playing around with timings, when I noticed that the two alerts you
suggested (showing iModTime and the file last modified time) were
consistently two milliseconds apart. so, I guessed at the syntax being
simple and put a minus two after file.lastModifiedTime. This actually works
- probably no surprise to you, but quite a surprise to me, I can assure
you!

i.e. it now looks like this:

function readBack(handler, sFilePath, iLastMod, iWaitCount){

try{
var file = Components.classes["@mozilla.org/file/local;1"]

.createInstance(Components.interfaces.nsILocalFile);
file.initWithPath(sFilePath);
if(file.lastModifiedTime -2 !=iLastMod || iWaitCount>180){
// read back output
......etc.

Anyway, I've now removed all the alerts and, from about 10 tests with
varying values on the hashcash value (from 20 to 40), the process now works
as intended :-)

Now, I realise that this is a cheat of some kind, and that I've not found
out why the two times are 2 milliseconds apart (apparently consistently),
but it does at least fix my problem. I'll be interested in hearing what you
find out about why this 2 millisecond discrepancy is occurring.

Let me know if you'd like me to do any more experimentation.

Mike

Hi Ali,

Thank you :-) This is quite fun actually ;-)

I tried the a version with the two alerts you specified:
alert('Recorded last mod time: ' + iLastMod);
alert('Current last mod time: ' + file.lastModifiedTime);

and the times are consistently different (with the java console still
open). At the point when the second alert comes up the console window is
reading: "INFO: minting HashCash....." etc.

So it looks as if (on my machine at least), the iLastMod variable and the
file.lastModifiedTime are different when they shouldn't be, so somehow the
file is registering as modified too soon :-/ (Obvious, I know, but it helps
me to write this down!).

I then tried the other aspect, the timeout value: changed the 500 in:
function runProcess(process, args, handler, sFilePath, iLastMod){
alert('Beginning of runProcess - alert changed from 500 to 5000');
try{
process.run(false/*no-block*/, args, args.length);
setTimeout(readBack, 5000, handler, sFilePath, iLastMod, 0);

...to 5000.

Having done that, there is a clear 5 second delay between the alert
dialogue boxes, so that's clearly working fine. (I set the hashcash value
to 30, so that the console window remained open for that period).

Looks as if iLastMod is getting a time which is slightly earlier than the
timestamp of file.lastModifiedTime (on my machine). Since I don't know
where the readBack function gets iLastMod from, I can't see anything to try
next....!

'Tis progress though :-)

Sov

Hi SoV,
Sorry i'm very occupied with something else at the moment, so the delay
in responding.
I must say you have all ingredients to make a very good programmer.
Yes the alert is a sort of delay as it is modal (which means the caller
pauses until the user presses OK)

Since the file is not held open during stamping, choice b is correct. "the
checking process is not correctly recognising the mod time on the file" ..
so we have to focus on debugging that.

Some tips I can give you are:
1. You can always revert back to the file originally supplied by pennypost
1.3 by:
a) un-installing and reinstalling the extension OR
b) unzip the ppost13.xpi file (yes it is a simple zip file) and you will
find all original files in there including ppost.js

2. The alerts can me made smarter by adding variables to them.
for example you can say:
alert('Hi you are at the beginning of the timeout line' + iLastMod);
This can give you a live output of what the variables currently hold (in
this case the value of iLastMod)

-----
Can you please change the alert in readBack()
alert('About to check the last mod time');
to two alerts

alert('Recorded last mod time: ' + iLastMod);
alert('Current last mod time: ' + file.lastModifiedTime);

See if the values are DIFFERENT in the first call itself (while the
console is still open).
The values should be the same as the console hasnt written anything to the
file yet, so the recorded time and the 'current' last mod time must be
identical, (until the console goes off and changes the file).

Also are the settimeout calls actually working? for example is there a
delay between the
runProcess() - alert('part way through runProcess');
and the readback alert? Timeout is in milliseconds so 1000ms = about 1
second delay.

Thanks & Regards,
Ali

Aha! I spoke too soon :-)

I have a number of alerts in the modified version of ppost.js (sprinkled a
few in for good measure). I have just found that, if I pause at the one
which says 'about to check the mod time', which is obviously just before
your line of code which does that, and wait for the java console window to
close, then say 'OK' to the 'about to check....' alert, it works every time
(I've set the hashcash to 30 so that I can confirm that this is correct.
i.e. wait 'til java console closes, then allow the script to progress to
checking the modification time on the file = success, consistently :-)

So, I'm just guessing, but it looks as if either a) the checking mod time
process does not work (for me) when the file is being held open (is it?) by
the hashcash process, or b) the checking process is not correctly
recognising the mod time on the file for some other reason which I don't
understand.

Apologies if the above is unclear, but I've never written code, so working
out what it's doing is a bit new to me. Hope this helps! I'll append the
modified version in case it's of any use (note that I've messed around with
the timeout numbers too - I'm not sure that was remotely necessary, but I
don't recall what they were originally now.....I think the key reason it's
now working, after a fashion, is that the alert is holding the script up
until I tell it to proceed based on the java console closing).

Sov

/* Penny Post - A postage system for email
* Copyright (C) 2007 Aliasgar Lokhandwala <d7@freepgs.com>
* http://pennypost.sourceforge.net/
*
* ppost.js: Utility functions
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
* (at your option) any later version.

* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.

* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/

var gStampTypes={ UNKNOWN:0,
S_UNKNOWN:'none',
HASHCASH:1,
S_HASHCASH:'hashcash',
MBOUND:2,
S_MBOUND:'mbound'
};

/**
* Tries to get the path of ppost.jar relative to the extension folder
* This jar is in the lib folder of the extension folder
*/
function getJarPath(){
try{
var eid = "{3748ced8-ae28-48ac-a954-4bff3360f72c}";
var ext = Components.classes["@mozilla.org/extensions/manager;1"]

.getService(Components.interfaces.nsIExtensionManager)
.getInstallLocation(eid)
.getItemLocation(eid);
ext.append("lib");
ext.append("ppost.jar");
if(!ext.exists()){
throw new Error('ppost.jar not found in '+ext.path);
}
}catch(ex){
Components.utils.reportError(ex);
//ignore
return '';
}
return ext.path;
}

/**
* Reads back from the file once the external process is done.
* We detect a change in file modification time to check if the
* process has changed the file.
*
* This function will give up after about 1 minute.
*
* This function compliments readFromProgram.
*
* @param handler
* The handler to cal once done or on error
* @param sFilePath
* The path of the file to monitor and read from
* @param iLastMod
* Last modification time of the file
* @param iWaitCount
* How long we have been waiting, in seconds.
*/
function readBack(handler, sFilePath, iLastMod, iWaitCount){
try{
var file = Components.classes["@mozilla.org/file/local;1"]

.createInstance(Components.interfaces.nsILocalFile);
file.initWithPath(sFilePath);
alert('About to check the last mod time');
if(file.lastModifiedTime !=iLastMod || iWaitCount>1800){
// read back output
var istream =
Components.classes["@mozilla.org/network/file-input-stream;1"]

.createInstance(Components.interfaces.nsIFileInputStream);
istream.init(file, 0x01, 0444, 0);
istream.QueryInterface(Components.interfaces.nsILineInputStream);

var line = {}, lines = '', hasmore;
do {
hasmore = istream.readLine(line);
lines+=line.value;
} while(hasmore);

istream.close();
alert('About to delete the temp file');

//delete the temp file
file.remove(false);
alert('Temp file deleted, in theory at least');

handler.finished(lines);
}else{
//continue waiting & checking
alert('Hi you are at the beginning of the timeout line');
setTimeout(readBack, 50, handler, sFilePath, iLastMod, iWaitCount+1);
}
}catch(ex){
if(handler.handleError){
Components.utils.reportError('Exception during readback ' + ex + ".
I've passed it on to a handler");
handler.handleError(ex);
}else{
Components.utils.reportError("Ignored exception during readback " +
ex);
}
}
}

/**
* Communicates with the external program to generate or verify stamps
* Handles invocation of external program and reading back of output
*
* This function will return immediately. The external program will
* run in the background and the handler will be notified when data
* becomes available.
*
* @param pref
* The Mozilla preference object
* @param outputParams
* An array of arguments to be passed to the program
* @param handler
* An object containing the finished method,
* which is called if the invocation was successful
*
* @return
* true on success, false on error
*/
function readFromProgram(pref, outputParams, handler)
{
try{
var javapath=null;
var path=pref.getCharPref('ppost.path');
var useJava=pref.getBoolPref('ppost.usejavalaunch');
if(useJava){
if(path.length==0){
path=getJarPath();
pref.setCharPref('ppost.path',path);
}
javapath=pref.getCharPref('ppost.javapath');
}

if((useJava && javapath.length==0) || path.length==0){
var msg=gStrBundle.getString("error_config");
alert(msg);
throw new Error(msg);
}

//create a temp file
var file = Components.classes["@mozilla.org/file/directory_service;1"]
.getService(Components.interfaces.nsIProperties)
.get("TmpD", Components.interfaces.nsIFile);
file.append("ppost.tmp");
file.createUnique(Components.interfaces.nsIFile.NORMAL_FILE_TYPE,
0666);

//write to temp file
var foStream =
Components.classes["@mozilla.org/network/file-output-stream;1"]

.createInstance(Components.interfaces.nsIFileOutputStream);

foStream.init(file, 0x02 | 0x08 | 0x20, 0666, 0); // write, create,
truncate
var sTempOut='ERR/stamp program did not respond in time';
foStream.write(sTempOut, sTempOut.length);
foStream.close();

//save last mod time
var iLastMod=file.lastModifiedTime;
//save filepath
var sFilePath = file.path;

//locate process file
var processfile = Components.classes["@mozilla.org/file/local;1"]
.createInstance(Components.interfaces.nsILocalFile);
var args = new Array();
if(useJava){
processfile.initWithPath(javapath);
args=['-jar',path, '-o',file.path];
}else{
processfile.initWithPath(path);
args=['-o',file.path];
}
args=args.concat(outputParams);

if(!processfile.exists()){
throw Error(gStrBundle.getString("application")+" "+processfile.path+"
"+gStrBundle.getString("error_noprog"));
}

// create an nsIProcess
alert('Hello again - you are about to creat an nsIProcess');
var process = Components.classes["@mozilla.org/process/util;1"]

.createInstance(Components.interfaces.nsIProcess);
process.init(processfile);

//we need some delay before actually running the process
//otherwise file-modification time is indistinguishable
setTimeout(runProcess, 1000, process, args, handler, sFilePath,
iLastMod);
} catch (ex){
if(handler.handleError){
Components.utils.reportError('Exception calling stamp program ' + ex +
". I've passed it on to a handler");
handler.handleError(ex);
}else{
Components.utils.reportError('Ignored exception in calling stamp
program ' + ex);
}
return false;
}

return true;
}

/**
* This function runs the process with supplied arguments
* and sets up the readback timer.
*/
function runProcess(process, args, handler, sFilePath, iLastMod){
try{
process.run(false/*no-block*/, args, args.length);
alert('part way through runProcess');
setTimeout(readBack, 2500, handler, sFilePath, iLastMod, 0);
}catch(ex){
if(handler.handleError){
Components.utils.reportError('Exception running stamp program ' + ex +
". I've passed it on to a handler");
handler.handleError(ex);
}else{
Components.utils.reportError('Ignored exception in running stamp
program ' + ex);
}
}
}

Hi Ali,

No joy with finding the problem myself I'm afraid - all I've achieved is
to make some messages pop up at various points in the process.... ;-) I
have to say, the editor you pointed me to is excellent though - thanks for
that!

SoV

Hi Ali,

Well I think this is a great extension and I'd really like it to work (for
me!). I shall resist the temptation to play with the code now as it's
midnight and I should consider getting some sleep....I'll have a go
tomorrow though.

It had occurred to me that the speed of this machine might be a factor,
when I realised that there was some kind of timing problem occurring. But
I'm not sure it's that fast relative to some peoples' desktop machines
though - it's a T61p Thinkpad, 2.4GHz dual core processor and 3GB of memory
- fastish disk too, though I don't see that that could be relevant.

Anyway, as soon as you have something to try, send it over!

SoV

Notepad can be a bad choice for editing these files.
Though they can be edited by any plain text editor, I normally use SciTE,
which treats unix and windows files more identically

http://scintilla.sourceforge.net/SciTEDownload.html

Hi SoV,
Thanks for the update and your help.
FYI, yes you can log the console output to file by adjusting parameters in
log.prop .. but we already know the problem is not with the program call as
the files are getting written to with correct stamps.

The thing that concerns me is that why the extension does not wait long
enough. Because the timeout is definitely long and works on most others
users (including my own) system.

One reason I see is that something marks the file as 'modified' before the
pennypost program writes to it. This causes the extension to read it back
pre-maturely and find it is empty and thus throw up that error.

Of course the other bug we have uncovered is that after detecting the file
is invalid, the stamp dialog should vanish and tell the user explicitly
that an error has occurred. Instead it seems to stick around waiting for
the user to get tired and cancel it off. Not good.

One thing I realise for sure is that your machine must be very fast,
because with a 18 cost hashcash the dialog should stick around for a while,
but it does not cause your cpu does the job quite easily. I wonder if the
speed is affecting the file timings... needs more thought... I'll look at
the code for stamp generation again and see if I can send you a modified
version to test in a few days time.

Just in case you are eager to experiment further, you can open up the file
<ppost>\chrome\content\ppost.js in notepad.
The way things get called in this file is
1. readFromProgram - sets up the program path and parameters
2. runProcess - runs the program first time, thats when you see the
console open
3. readBack - checks back periodically for o/p

A simple way of finding out whats happening is by putting in a line like

alert('Hi you are here');

if the alert shows you know that line was executed.

The function that needs investigation is obviously readBack()


-Ali

And further......

I checked the temporary folder and there are (were!) 353 ppost.tmp files.
They all (well, a significant, random sample) contain what I take to be
valid hashes of the form:
OK/1:25:071014:email@mydomain::912ecb9cf919c0a5:310a57f1

So, definitely looks as if the extension is not waiting long enough for
the hash to complete. The actual time it waits is sub 2 seconds - it seems
to give the timeout error almost as soon as the console window opens (this
is not a slow machine!).

SoV

Hi Ali,

OK, I tried that with the following results:

The console window pops up, but is only there for about half a second
usually, so I can't see what is happening. Occasionally it's taken up to 2
seconds, and I can see that it's calling the hash function - the problem is
that it disappears as soon as that ends (two lines of text flash up, but no
way can I see what they say!). Does the console get logged somewhere? I've
looked but can't find it.

I'm guessing that the variation in time is down to the variable time the
algorithm takes, which would tend to suggest (to me, and I'm not a
developer and don't understand this stuff...) that it's completing (since
the time varies and the console always vanishes immediately after the last
two lines flash up) and then that the penny post process is not detecting
that the file has been written/changed.

AHA! I tried putting in a large value for hashcash (60). I can now see
that the java console gets to "INFO: Minting Hashcash/1/60/...." and that
the T'bird error console shows the two timeout errors almost immediately
after this stage is reached. i.e. it appears as a timing issue. I'll leave
the first couple of paragraphs here in case there's any meaningful info. in
there ;-)

Thanks for pursuing this!

SoV

Hi SoV,

The error ppost_messageComposeOfflineObserver is not defined is a
pennypost bug. But has nothing to do with the stamping operation. It is a
minor error and can be ignored. (I've fixed it for the next release though.
Thanks.)

The errors with chrome://messenger/content/ were due to a mixed-up install
and should be fixed now since you cleaned everything.

Now let me give you an overview of how the stamp generation actually
works. The extension creates a file in your temporary folder %tmp% on
windows the invokes the pennypost program via JVM. The program is supposed
to write the output back to the file. Meanwhile the extension keeps
checking the files modification time to see if the program has written
something in. If the modification does not change, after some time the
extension gives up and declares that "The stamp program did not respond".

A couple of things could be going wrong here,
Before you begin, locate the extension in you thunderbird profile folder
in the folder:
%userprofile%\Application Data\Thunderbird\Profiles\

Pennypost will be in extensions\{3748ced8-ae28-48ac-a954-4bff3360f72c} ..
i'll call this folder "<ppost>" for short

See if the stampprogram is failing to generate the stamp. To confirm this,
you need to use java.exe instead of javaw.exe and also in the <ppost>\lib
folder delete or rename log.prop.
Now you will be actually able to see pennypost generate the stamp in a
console window. See if this process happens w/o error.

If the extension displays an error before the program has completed stamp
generation, the issue is a timing issue (the extension should have waited
longer). If the program completes but the extension is still unaware that
the program is done, it is a file modification detection issue.

Let me know what you find. My guess is that this is a timing issue.

Regards,
-Ali

I have now:

1. Completely removed T'bird and re-installed, including removing all
registry settings so that it was entirely 'clean', with no mail and no
extensions except Penny Post.
2. Tested Penny Post, starting with a cost of 1 in hashcash (no other
defaults changed).
3. It consistently works up to a cost of 10. Thereafter, incrementing by 1
and testing each time, it generally fails beyond 17. I once had a
successful trial with 18, but generally 17 is the limit. This is not 100%
consistent, in that sometimes it will be working at 17 and then fail on
some occasion (with the two errors in the log as before). REducinig to 10,
running it after a T'bird restart, then gradually incrementing to 17 again
generally works, but not always :/

Perplexing. Apologies that I have not yet found a consistent behaviour.
Incidentally, the only applications I have running when testing are T'bird,
Firefox, Vista task manager and notepad.

4. I've now re-installed all extensions and re-instated my mail and the
behaviour is the same - note that the two erros on opening the mail send
window have now gone though (I re-installed all extension on the clean
copy, rather than just moving the entire T'bird profile across.

SoV

More info.:

When I cancel stamp generation, no more errors appear; when I then close
the T'bird compose window, the following two errors appear in the log
1. Error: ppost_messageComposeOfflineObserver is not defined
Source File: chrome://ppost/content/composeOverlay.js
Line: 90
2. Error: sMsgComposeService is not defined
Source File:
chrome://messenger/content/messengercompose/MsgComposeCommands.js
Line: 1064

Ho hum :-(

SoV

Hi Ali,

I wondered if my Thunderbird installation was suspect, but it was a bit
late to carry on fiddling....

So:

1. I re-installed Thunderbird 2.0.0.6 (over the top of the existing
installation, not 'clean'. This resulted in the same behaviour, with the
infinite message stamping dialogue every time I tried to stamp something.

2. Disabled all extensions in T'bird except Penny Post (and restarted, and
confirmed that they are disabled!). This gives the two pertinent errors in
pennypost still :-( i.e.
a) Error: Exception during readback Error: Program failed to generate
stamp for mikey@cliffhanger.comReason: stamp program did not respond in
time. I've passed it on to a handler
Source File: chrome://ppost/content/ppost.js
Line: 101
b) Error: Error: Program failed to generate stamp for
mikey@cliffhanger.comReason: stamp program did not respond in time
Source File: chrome://ppost/content/stampProgress.js
Line: 189

To answer the first questions, now that I've confirmed that it's not, so
far as I can see, an extension clash:
1. yes, it happens every time I use Penny Post;
2. no, this was a problem with 1.2.4 as well.

A bit more background is that Penny Post *has* worked, but only for low
values of hashcash. I got up to 17 when experimenting once, which stamped
in a couple of seconds, then changing hashcash to 18 resulted in the
infinite wait, which now seems permanent, even when I try putting hashcash
at 1. Very odd :-(

Thanks for coming back to me so quickly! Happy to try some experimentation
if you point me in the right direction. Right now, I'm going to try
un-installing Thunderbird and all extensions, as far as I can do, and see
if I can get it to work from a 'clean' install.

SoV

Hi Ali,

I wondered if my Thunderbird installation was suspect, but it was a bit
late to carry on fiddling....

So:

1. I re-installed Thunderbird 2.0.0.6 (over the top of the existing
installation, not 'clean'. This resulted in the same behaviour, with the
infinite message stamping dialogue every time I tried to stamp something.

2. Disabled all extensions in T'bird except Penny Post (and restarted, and
confirmed that they are disabled!). This gives the two pertinent errors in
pennypost still :-( i.e.
a) Error: Exception during readback Error: Program failed to generate
stamp for mikey@cliffhanger.comReason: stamp program did not respond in
time. I've passed it on to a handler
Source File: chrome://ppost/content/ppost.js
Line: 101
b) Error: Error: Program failed to generate stamp for
mikey@cliffhanger.comReason: stamp program did not respond in time
Source File: chrome://ppost/content/stampProgress.js
Line: 189

To answer the first questions, now that I've confirmed that it's not, so
far as I can see, an extension clash:
1. yes, it happens every time I use Penny Post;
2. no, this was a problem with 1.2.4 as well.

A bit more background is that Penny Post *has* worked, but only for low
values of hashcash. I got up to 17 when experimenting once, which stamped
in a couple of seconds, then changing hashcash to 18 resulted in the
infinite wait, which now seems permanent, even when I try putting hashcash
at 1. Very odd :-(

Thanks for coming back to me so quickly! Happy to try some experimentation
if you point me in the right direction. Right now, I'm going to try
un-installing Thunderbird and all extensions, as far as I can do, and see
if I can get it to work from a 'clean' install.

SoV

Also looking at some of the errors related to chrome://messenger/content/
... these are thunderbird internal files and should not be generating
errors. It seems these errors have happened when you opened the compose
window. Do they appear each time the problem happens? Try re-installing
thunderbird once... or disable all other extensions besides ppost... just
in case something else is also interfering with the compose process.

--Ali

hi Sea,

Thanks for the logs... I now have an idea of where the problem lies.
Tell me:
1. Does the problem happen every time you generate stamps or some times?
2. Is the problem happening with v1.3 of ppost only?

I will probably need to give you some replacement files that will generate
additional messages and will help us nail the problem.

Thanks,
--Ali

CORRECTION:

With a compose window already open, and the error log clear, only the last
two messages are generated when I hit the 'generate stamp' button!

Sorry!

I have the same issue, except that it *usually takes hours. I'm using
Vista Ultimate, Sun Java 6.0.3, V.1.3 of Pennypost and the latest version
of Thunderbird. On clicking the 'generate stamp' button, I can see
javaw.exe start up in task manager, for less than a second, and then the
'generating stamp' dialogue just sits there for minutes (I've never waited
hours) before I cancel it. There is no cpu being used by any pennypost task
(that I can see). The following errors appear in the error console
(starting with it clear, then hitting the 'generate stamp' button.

Error: ppost_messageComposeOfflineObserver is not defined
Source File: chrome://ppost/content/composeOverlay.js
Line: 90

Error: sMsgComposeService is not defined
Source File:
chrome://messenger/content/messengercompose/MsgComposeCommands.js
Line: 1064

Error: [Exception... "'JavaScript component does not have a method named:
"NotifyComposeBodyReady"' when calling method:
[nsIMsgComposeStateListener::NotifyComposeBodyReady]" nsresult:
"0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)" location: "JS
frame :: chrome://messenger/content/messengercompose/MsgComposeCommands.js
:: InitEditor :: line 3586" data: no]
Source File:
chrome://messenger/content/messengercompose/MsgComposeCommands.js
Line: 3586

Error: bUpdateUndoButtons is not defined
Source File: chrome://buttons/content/composeWindow.js
Line: 146

Error: Exception during readback Error: Program failed to generate stamp
for mikey@cliffhanger.comReason: stamp program did not respond in time.
I've passed it on to a handler
Source File: chrome://ppost/content/ppost.js
Line: 101

Error: Error: Program failed to generate stamp for
mikey@cliffhanger.comReason: stamp program did not respond in time
Source File: chrome://ppost/content/stampProgress.js
Line: 189

Does any of the above indicate whether I have a configuration problem, or
whether it's a problem in pennypost?

Thanks,

Mike

Hi,
It is possible that an error occurs during the process. Next time it
happens, have a look at the error console (Tools menu->error console) and
let me know if you find any errors coming from pennypost. Besides that
scientifically algorithms like hashcash and mbound have no upper-bounds for
stamp generation time so it is possible that you get very unlucky
sometimes.

-Ali