[hashcash] minimal stuff for debian release? (Re: Re: status of hashcash version 1?)
- From: Adam Back <adam@xxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Tue, 3 Aug 2004 15:37:35 -0400
On Tue, Aug 03, 2004 at 02:44:52PM -0400, Hubert Chan wrote:
> Personally, my vote would be for just getting a stable v.1 out so that
> it can be pushed into the next Debian stable (the release managers are
> hoping for a general freeze within a couple of weeks -- the freeze of
> the base system is already underway). I'd just compile for a generic
> system. If the fastmint stuff gets merged, I'll compile fastmint_mmx
> with the mmx flags and everything else without, and hope that the CPU
> detection code works (I guess it's time to dust off Bochs for
> testing). Similarly for Altivec. I'd rather have a slow (but working)
> hashcash in Debian stable than to have no hashcash. After that
> happens, then I'll start worrying about performance.
>
> (Of course, Adam is free to have his own opinions on release schedule.
> This is just my view from the Debian side of things.)
I agree. Well any of Jonathan's generic C cores are already way
faster than what I have in hashcash-1.00.
We're just trying to fixup a stable safe v1 reading and writing
hashcash client to put in debian which releases soon.
Once that's done we can go back to the assembler detection and have
then more time for people to test-it-for-us and complain and fix
etc. on different processors. And then that can go into later
distributions of debian and other distributions that may choose to
pick up the faster version after it has seen more testing.
I could use a bit of help as I also have a work deadline over the next
couple of weeks and so limited time at the moment which is an
unfortunate double deadline on debian. And guess which takes
precedence.
Here is my TODO list:
v1 code:
* rev the version number /
* add separate counter field (simpler logic from Izzy) /
* deal with wrapped lines on -cX
* get rid of stamp size limits (to allow extensibility)
* integrate Jonathan's code
* change timing to use clock() instead of wall-clock time
* add back support for v0 format??
==== nice but after debian ====
* are any of the time calls, or other calls also not thread safe?
* add extension support (ie exec sub-programs)
* add option to apply URL encoding to the resource arg?
* add BerkleyDB support
* remove mallocs
* remove strtok use, not thread safe
rubric: / means done, " x" means not going to do
As Hubert commented actually supporting extensions is much less
important than being able to ignore them. The current code can ignore
them. Thread safeness can wait. DB performance can wait (berkelydb
or others rather than current crappy linear text file).
Any takers of todo items or suggested promotions or demotions from
debian release? Any other debian must-fix problems I'm missing?
Adding back support for reading (but not generating) v0 format -- I
guess we need this as it is deployed in a few places tho not too
vastly.
Packaging can stay as is I think (.rpm, .deb)
Adam
Other related posts:
