Re: Auto-discard notification

Hmm openvpn do it that way

Thu Jul 07 23:08:47 2005 Cannot load certificate file 
D:\programme\openvpn\confi
g\client.crt: error:0906D06C:PEM routines:PEM_read_bio:no start line: 
error:140A
D009:SSL routines:SSL_CTX_use_certificate_file:PEM lib

that is what i ment :-)
adantage of this is that sometimes "cannot load" doesnt mean nessesary file 
is not there, ther ecould be another issue
here you see every involed function which maybe lead to a false understood 
error msg

but it doenst matter, yes bit more human readable will reduce the need of 
additional help
or make it a lot easier to help. Honnestly error -5 hmm lets guess :-)

or make just errorcodes and we offer professional support and charge it lol
of course in that case we change those codes every 2 weeks...
sorry just a few evil thoughts - yes microsoft shoud hire me


-----Ursprüngliche Nachricht-----
Von: Stevan Bajić [mailto:[email protected]]
Gesendet: Montag, 9. August 2010 13:57
An: [email protected]
Betreff: Re: [Dspam-devel] Auto-discard notification

On Mon, 09 Aug 2010 11:22:40 +0000
"Imposit.com - Webmaster" <[email protected]> wrote:

> I would say a function for error Handling with an optional argument
> errorcode where is needed.
> The errorcode can be translated in the function to something human 
> readable
>
Okay. So you are all for extending the current functions to return more then 
just plain success/failure?


> on the other hand the idea slo the whole chain for the error is not bad.
> openvpn do it that way
> is a bit cryptic to read but if you read carefully you know exactly what 
> is
> wrong
>
This is the way how it is now implemented in DSPAM.


> -----Ursprüngliche Nachricht-----
> Von: Stevan Bajić [mailto:[email protected]]
> Gesendet: Montag, 9. August 2010 11:48
> An: [email protected]
> Betreff: Re: [Dspam-devel] 3.9.1-rc1: issue with classification user
>
> On Mon, 09 Aug 2010 10:31:34 +0100
> Paul Cockings <[email protected]> wrote:
>
> > Stevan Bajić wrote:
> > >
> > > {function a} -[calling]-> {function b} -[calling]-> {function
> > > c} -[calling]-> {function d}
> > >              |
> > >              +[calling]-> {function e} -[calling]-> {function d}
> > >                                        |
> > >                                        +[calling]-> {function f}
> > >
> > >
> > > This is the reason I wrote "it is not that simple".
> > >
> >
> > I love your explanations, so clear and easy to understand. :-)  .. a
> > true expert.
> >
> > If there was skill, time and motivation to change this, what would be
> > the correct solution in your opinion?
> >
> "Correct solution"? It's hard to tell. Mainly because you can not just 
> look
> at one problem and say that this or that is the correct solution. You need
> to look at the whole solution/code in order to say what would be the best
> solution.
>
>
> > 1. Stay with 'a bunch of functions' but add better error communication
> > between functions
> >
> This will probably break the purpose of libdspam.
>
>
> > 2. Rewrite the complete structure using something other than 'a bunch of
> > functions'  (aka Dspam 4 along with a LOT of other things half 
> > discussed)
> >
> That could be one way of solving that issue. I don't mean just rewriting 
> the
> functions but rewrite the way how errors are passed from one function to 
> the
> other. Maybe unifying the error codes so that functions don't just return
> success/failure but do more. Another way would be to create something like 
> a
> stacked/logged error queue. Something where the calling "function a" could
> then evaluate the whole calling path and then be able to print out that it
> failed because of this and that and not be just limited to know that
> "function b" has failed.
>
>
> > Forgive me if the question has an obvious answer (in a developers eyes)
> >
> >
> >
> > ------------------------------------------------------------------------------
> > This SF.net email is sponsored by
> >
> > Make an app they can't live without
> > Enter the BlackBerry Developer Challenge
> > http://p.sf.net/sfu/RIM-dev2dev
> > _______________________________________________
> > Dspam-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/dspam-devel
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Dspam-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspam-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Dspam-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspam-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Dspam-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspam-devel