----Mensaje original----
De: mar...@martinpaljak.net
Fecha: 24/01/2011 12:46
Para: "OpenSC-devel (opensc-devel)"<opensc-devel@lists.opensc-project.org>
Asunto: Re: [opensc-devel] [opensc-commits] Fwd: IAS sucks
[...]
> One of the longstanding problems of OpenSC is lack of documentation, both
> developer
> (source comments, internal architecture, tutorials on how to add new card
> drivers other
> way than copypaste etc) and end-user docs. This is unfortunately quite usual
> for open source projects, especially for niche project that does not attract
> a huge
> crowd of volunteers and where some companies could even sometimes take lack
> of documentation as a competitive edge.
> This is not a trivial thing to fix, especially for source code, which is not
> as "sexy"
> as end-user documentation.
> Not that I would want to suggest a "8 meters requirement" [1], something
> should be done about it.
[...]
I agree:
In the writting of Spanish DNIe LGPL driver I've found so many times that lack
of information.
A simple tutorial for writting card drivers, An overview of what iso7816.c
does, differences
between sc_xxx functions an their counterpart iso_xxx functions,
how sc_transmit_apdu handle 61xx status response,
how an when issue apdu->{resp,resplen,le} and what should be expected....
At this moment, I'have cwa14890 Secure Messaging working for DNIe,
but I'm next to !wrap and rewrite! sc_transmit apdu()... because I _really_
doesn't
know the exact way of handling a correct get_response() (required on every SM
apdu message)
cmd when expected data length is not known in advance or when a previous
function is already
waiting for a response in their apdu
So I really (really!) need a documented API and description on what is expected
for each routine
Perhaps not indeed to make a public API ( opensc-devel ), just a short of
"Developer's guide"
[...]
> Overall, the goal would be to increase the effort needed to figure out "how?"
> to code right now (not just write code but do some research and refactoring
> if necessary) and reduce the time needed later to figure out "why?"
> certain source code exists.
[...]
My DNIe code [1] already follows Doxigen conventions. Comments/total line ratio
is greater
than 20%. I'm also writting a development diary[2]... Well, my SVN commit
comments
perhaps should be improved :-)
About rewrittng and commenting... well, revise every files on Opensc may lead
unpractical,
and would be better for us to (re)write wiki documentation.Not sure
Anyway, regardless of mainstream comments in source code, I expect get DNIe
ready
for public test at the end of this month. Frank, Victor, perhaps you can find
usefull to
take a look to cwa14890 SM code
Juan Antonio
[1]
https://forja.cenatic.es/plugins/scmsvn/viewcvs.php/opensc-opendnie/?root=opendnie
[2] https://forja.cenatic.es/developer/diary.php?diary_user=5382
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
