On Wed, Jun 19, 2013 at 9:04 PM, SiegeLord <[email protected]> wrote:
> On 06/19/2013 04:01 PM, Corey Richardson wrote:
>
>> Please discuss, give me your feature requests, comments, etc.
>
>
> I am unclear why the XML/JSON is part of the parsing/extraction step, it
> seems like it's on the same level as the generator step. I.e. after the
> parser/extractor/filter do their thing, the XML generator will take the
> internal representation and create an XML file for external tools to do what
> they want with, just like is done with Markdown for pandoc. I don't see what
> good the XML is with all the extra indentation that is only removed a step
> below, but without useful things like the brief descriptions. Speaking of
> brief descriptions... this might not be a concept that is universal to all
> generators (e.g. sphinx doesn't seem to use them).
>

Brief descriptions would be ancillary data, optional for a backend to
use. For certain outputs that filter wouldn't even be included if it
doesn't make sense.

> I'm not sure what differentiates the filter step from the extraction step.
> Is it meant to be done in parallel while the rest is done serially? Overall
> it's not clear which steps are to be done in parallel (which should be
> expanded upon, as it seems to be one of the main motivations behind this).
>

So here is a diagram of what I envision happening:
https://gist.github.com/cmr/5819695

At any point, rustdoc can stop and barf out a XML/JSON document(s).
Otherwise it's all in its internal representation.

Filter order will be configurable (similar to how rustc currently
accepts a --passes argument for llvm optimization passes)

> Overall I guess what I'm really not clear about is how this is different
> than what is done today design-wise (aside from the multiple backends bit).
> It seems to me to be mostly a refactoring effort.
>

brson said he had ideas and would review my proposal. I've only been
using rust for the past ~month, and I never worked on rustdoc before,
so I don't know how sane it is or if there is a better thing to use.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to