Stefan Seifert wrote > >> A streaming API which defines a handler with a method that gets the name >> (or path?) and the map of properties would avoid having this additional >> tree api. I don't see a huge need to be able to have an api to traverse >> the parsed content. If any user of the contentparser really needs it, it >> can use whatever it wants. > > a Stream API would be a good solution for one half of the use cases. > the other half benefits from a Traversing API - we may leave it to the other > bundles and live with some code duplication. > > before dropping traversing API completely - what about this: we rename the > traversing API to something that makes it obvious that this is not > yet-another-content-representation-api but only a tool to hand over data - > e.g. "ParsingResult" instead of "Content"? > > the solution could be: > - offer a Streaming API > - offer an optional handler based on this streaming API that produces a > "ParsingResult" that has the minimal traversing capabilities as outlined in > the PR. > > we could even put this in two separate modules, but this feels a bit > over-engineered. >
I guess whatever we name it, it's another traversing API :) I would prefer to go with just the streaming api and only if really really really needed by many others start about thinking how to solve that. Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
