> On 13 Mar 2017, at 14:24, Bertrand Delacretaz <bdelacre...@apache.org> wrote: > > Hi Stefan, > > On Mon, Mar 13, 2017 at 9:48 AM, Stefan Seifert <sseif...@pro-vision.de> > wrote: >> i've recently created a new commons sling component which i named "File >> System Content Parser"... > > Great, thanks for this! > > Are you planning to reuse this in the Sling Content Loader? IIUC it > implements the same formats? -> already opened https://issues.apache.org/jira/browse/SLING-6634 for that > >> ...the question is - what should be the final name of this component... > > IMO it's parsing streams of content - taking a File as a parser > parameter is just a convenience. > > I would actually remove the parse(File) methods and keep only > parse(InputStream) for the sake of minimalism. But no strong opinion. > +1 on that one. Currently the implementation for File also doesn't do any buffering, so probably is not performing very well (https://github.com/apache/sling/blob/trunk/bundles/commons/fscontentparser/src/main/java/org/apache/sling/fscontentparser/impl/JcrXmlContentFileParser.java#L60). Also the implementation for all parser types will actually look more or less the same.
> So IMO "contentparser" is the right name, also as we already have > "Content Loader". > > I'm fine with leaving it under bundles/commons as it has no Sling > dependencies. > > Shouldn't the TestUtil.getDeep method be part of an exported utility > class? And maybe named getByPath? > It looks generally useful and the kind of code that people will > rewrite and get wrong ;-) > > -Bertrand
