[Webfunds-commits] java/webfunds TODO_SCW

Wed, 16 Aug 2000 15:51:48 -0400

Edwin Woudt wrote:
> 
> >  I.  Sanity checking is needed:
> >
> > +  (* that these are all potential checks may be also conducted within
> > +   Contract.verify, now called in FinishSig after Signing.  But, earlier
> > +   checks would be good too.)
> 
> If you can provide a verify method that works on an unsigned contract
> without keys, then an early check is trivial to implement.

Yes, this is the best place for doing a lot of that.

> BTW: it is very unclear to me in this list which things are fixed and which
> not.

(I've look at this just now, but main thing is to look at the other mail
I sent!)

* indicates stuff checked after signing in verify, but would be good
to check before signing, in appropriate dialog.

(DONE) indicates the only one that has been fixed, AFAIK and is left
there for completeness.

I've cleaned it up and committed.

> > +      I.a)  Contract - all these can be repaired and saved on the fly
> > +
> > +        + no trailing spaces
> > +        + uniform line endings
> 
> OpenPGP removes these automagically, so I would consider these fixed.

Trailing spaces is a matter of cleanliness only.

Uniform line endings is more a matter of communications,
once it is saved with the wrong line ending for the platform,
strange things start to happen with other tools & comms.

These are lower priority.

> > +        + for the secret key, wouldn't a popup box be better for the
> > passphrase? (one presumes this signals that the key is quickly
> > decrypted, used, then the decrypted version is disposed of
> > quickly...  may not be the case.)
> 
> Would probably be better, but was harder to implement, so that's why I went
> with the popup box.

Yes, nice to fix one day (presume you mean with in-dialog box).

> > +      I.d) Signed Contract
> > +
> > +        * signature made is correct and verifiable with contents of
> > contract no additional chars introduced, strip sig and keys
> > and diff with initial prototype contract.
> 
> I have got no clue what you are trying to say here.

I've rewritten it.

> >  II. Presentation.
> >
> > +        Some of the notes assume that the concept of "Wizard" is
> > modifiable, (as discussed...) which may be a bad assumption.
> 
> I don't remember this discussion, and I don't think most people on -devel
> have seen this. Could you eleborate?

It was verbal last night with Jeroen!  see below.

> > +    d.2 Needs a save button to save out that file to the original
> > +        Name or a browsed name.  Need to recall the name.
> 
> Save button is a bad idea, as it defeats the idea of a wizard, but yes it
> is a good idea to have a similar feature.

This was indeed gist of conversation; that a Wizard does things as it does
things and changing it is not a Good Thing (tm).

My comment on that is that I need these features to make the code
usable and workable in the face of users.  If the user interface
for a Wizard is unchangeable & A Bad Thing (tm) then I'm quite happy
if the changes are made and we change the name to Warlock, Witch,
or any other Wonderous Thing (tm).

The problem with not having the Save button (and other non-Wizard
features) is that I and other contract writers have to go through this
dozens of times before we get it right, so we end up walking thru
the process so many times that we tear our hair out over doing the
same 3 minute typing process over and over and over....
-- 
iang