>
> 1) build: something is missing from README because
> xsbuilder/xs_generate.pl was looking for xsbuilder/maps and couldn't
> find it. I've added a symlink similar to xsbuilder/xs and then it
> worked. shouldn't it look for xsbuilder/xs/maps instead?
>

makeing the symlink was the right thing to do. I forgot it in the README.
The next version should work without these symlinks, only taking the value
from config.pl, but I didn't had the time to implement it yesterday and I
really wanted this thing o get out...


> 2) layout:
>
> Here is a snippet from perldoc's output on Apache/RequestUtil.pm
> (indented to the right) with comments starting at /^/:
>
>         Apache::RequestUtil
>
> To save typing would be a good idea to start the functions with:
>
> =head1 Functions
>
>         @func: default_type()
>
>         $ret = $r->default_type()
>
> semicolon would be nice
>
>         @param: Apache::RequestRec $r
>             The current request
>
> would be nice to add the markup: C<L<Apache::RequestRec>> C<$r>, or
> should this be done at the final conversion stage? It actually should
> be
> C<L<Apache::RequestRec|docs::2.0::api::mod_perl-2.0::Apache::RequestRec>>
>

I would do this in the final conversion state, since we decided that this
docs that are generated in stage 1 are only contain content, while the
layout is added in stage 2

>         @ret: PV
>             The default type
>
> C struct types aren't really useful to Perl programmers, I guess this
> can be converted in the final pod (e.g. PV => scalar, AV => list,...)
>

Yes, of couse, we should convert it.

>         @since: 2.0.1
>
> 2.0.1 is an Apache version, Shouldn't this be a mod_perl version?
> suppose it should say since: httpd-2.0.1, mod_perl-1.99_apr-0.9.1
> whatever is appropriate?
>

For now this is hardcoded in WrapXS.pm and only a placeholder for some
information that makes more sense. I am not sure how we can get this
information? Any ideas?

>         Retrieve the document root for this server
>
> May be put the short description first? And then full desc after the
> usage?
>

Mostly we only have one short description.


>
> ...
>
> In general < and > should be escaped E<lt>, E<gt>

Yes

>but we probably should
> do better in cases like: Apache/RequestIO/RequestIO.pod:
>
>         @param: Apache::RequestRec $read_policy
>             How the server should interpret a chunked transfer-encoding.
>   One
>             of: <pre>
>                 REQUEST_NO_BODY          Send 413 error if message has
> any body
>                 REQUEST_CHUNKED_ERROR    Send 411 error if body without
Con-
>             tent-Length
>                 REQUEST_CHUNKED_DECHUNK  If chunked, remove the chunks
> for me.
>             </PRE>
>
> should probably convert <pre> by adding a separating new line and making
> sure that a 2 chars leading space starts every line of <pre>, including
> empty lines.
>

Yes

Gerald


-------------------------------------------------------------
Gerald Richter    ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:       Tulpenstrasse 5         D-55276 Dienheim b. Mainz
E-Mail:     [EMAIL PROTECTED]         Voice:    +49 6133 925131
WWW:        http://www.ecos.de      Fax:      +49 6133 925152
-------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to