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-----