Re: Re: Private API documentation, win32 msvc port
Wesley Leggette <lists-+42/j/[email protected]> Thu, 24 Mar 2005 23:40:19 +0100
| Newsgroups | gmane.comp.sysutils.backup.dar.general |
|---|---|
| Message-ID | <1111704019.12297.38.camel@localhost> |
On Thu, 2005-03-24 at 22:06 +0100, Denis Corbin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Wesley Leggette wrote: > | Denis, > | > > Hello Wesley, > > > | As I may have told you, I'm working on porting libdar to win32 msvc [1]. > | As part of that, I've been trying to seperate out where native linux > | calls are placed. > | > | Right now, I'm trying to divide out the documentation to reflect this > | kind of thing. Here's the categories I've come up with: > | > | - Backup filesystem interface > | Classes that deal directly with the filesystem on the backup side > | (reading in inodes and converting them to catalogue entries). > | - Archive filesystem interface > | Classes that deal directly with the filesystem on the archive side > | (reading and writing archive files). > | - File filters > | Encryptors, compressors, and other slice to archive kinds of > | things. > | - Catalogue objects > | Classes that represent catalogue entries. > | - Archive structure > | Various other classes (header, slice header, etc). > | > | I've attached a patch of apidoc changes if you're interesting in this > | sort of thing. > > many of the objects you have seen are not part of the API (catalogue > objects, archive structure, archive filesystem interfaces, file filters, > and so on). While I agree that a correct source code is one which is > documented (and also commented in the source when necessary), theses > classes have not their place in the api documentation. > > Because having theses descriptions in the API class reference may make > API user confused or may make them use classes that they have not to > use, leading to some users complaining of internal changes. I would > rather make a separate document, maybe... no? That's a good idea. I will continue my work as a seperate doxygen document. Wesley. > > | > | Thanks, > | Wesley > | > | > | > > Cheers, > Denis. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFCQyvupC5CI8gYGlIRAtmCAJwNfVl1jSoPlF0XHRktZ3o3rl2lnQCeIHt2 > v/E/kV+Jknu5JnN6F6SGCNY= > =TiRM > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Dar-discussions mailing list > Dar-discussions-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/dar-discussions -- Wesley Leggette <lists-+42/j/[email protected]> GPG Key: http://www.kaylix.net/kaylix.asc or http://pgp.mit.edu GPG Fingerprint: 9B6F 19FB 5296 5E6C 21FE 7614 2A20 5688 F848 9BDD
signature.asc
(application/pgp-signature, 189 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQBCQ0HSKiBWiPhIm90RAvmzAJ4wK5hjCCa/O3pdPUjRxFe1R0j9CACggP4q K8fjfxaO7Yyga37L1bpjCrY= =OGxG -----END PGP SIGNATURE-----