A shorter prefix like just "daf-" would bother me less. It literally becomes screen-real-estate using IDEs because the project trees extend from the left of the screen, and they just go too far right before you get to the actual files contained. ________________________________ From: Steve Lawrence <slawre...@apache.org> Sent: Monday, October 5, 2020 11:25 AM To: dev@daffodil.apache.org <dev@daffodil.apache.org> Subject: Re: Subproject names proposed for discussion
Your suggestion seems reasonable to me. Adds a few more top level directories by splitting lib and schema-compiler which I'm not a huge fan of, but it is logical and reduces the size the lib jars. The one thing I like about the "daffodil-" prefix is it makes the code directories stand out a bit more. For example, the containers, project, target, tutorials, etc. directories or more about infrastructure. It makes it eaiser to ignore those when scanning through directories (of which this change would add quite a few more). I think this is also pretty common among java projects, but I don't think they all do it. But I'm not sure if either of those are strong reasons to keep it. We have had problems with long paths in the past on windows, so removing the prefix could help with that... On 10/5/20 11:11 AM, Beckerle, Mike wrote: > Some reponses inline below > > ________________________________ > From: Steve Lawrence <slawre...@apache.org> > Sent: Monday, October 5, 2020 10:48 AM > To: dev@daffodil.apache.org <dev@daffodil.apache.org> > Subject: Re: Subproject names proposed for discussion > > A handful of unrelated thoughts, maybe overthinking things and I don't > feel strongly about anything below, but renaming is always pain so it'd > be nice to ensure we have something future proof. > > 1) Is there any benefit organizationally to having all backends being in > the same directory? > > I think the opposite. I think they should be separate and top level in fact, > so that we're not tied to say, sbt build system as we are now. > > 2) From a sorting perspective, it'd be nice if the scala projects were > together, so having it be scala-parser and scala-unparser rather than > parser-scala and unparser-scala has advantages. > Agree. > > 3) Maybe the scala parser/unparser should be considered the same "scala" > runtime, and so parser/unparser should be subdirectories of a > "daffodil-backend-scala" subdirectory? > > There is no reason to keep the scala parser and unparser separate. > > That was done at one time because compilation time was so long that we wanted > to be able to close the unparser project (on eclipse) and not be recompiling > it if just doing work involving the parser. This is less an issue now. > > 4) Is there even a benefit to separating parser/unparser into separatejars? > There's so much shared logic between the two, and there's even a > bunch of unparsing stuff in the parser jar. Should we just combine them > under the same backend? > > Yes, but one step at a time. First I would do the renaming. I'd do the > merging of parser/unparser into one lib separately. > > Taking all of the above into account, perhaps something like this: > > ... > |-- daffodil-backends > > I would not add the backends parent. > > daffodil-backend-scala > > | |-- daffodil-scala > | | `-- src > | `-- daffodil-generator-c > > I would call the above daffodil-c-generator to be consistent. It is > important that this is identified as a generator. > > While we're at it, can't we drop the "daffodil-" prefix on all these? > > | `-- src > |-- daffodil-lib > | `-- src > |-- daffodil-schema-compiler > > This is problematic because each back-end is going to have its part of the > schema compiler that converts grammar objects into back-end primitives code > by generation of code that calls libraries. > > This should be distinguished from the 100% static code part of the back-end > which is statically written and testable independently. > > | `-- src > ... > > 5) Is there something better than "backend" for describing these. I > can't think of anything. Does the DFDL spec have a concept of this? > > There is no concept of this in the DFDL spec to borrow from. > > 6) Are there any benefits to using "codenames". My thinking is maybe > someday there could be multiple "scala" backends with different > goals/extensions, and so "daffodil-scala" is too generic. Codenames > would be more like what we have today, except real code names might be > easier to remember than "runtime1" and "runtime2". Disadvantage is > there's less discoverability, but a README could be added with short > descriptions about what the backends try to accomplish. Not sure I like > this, but thought I'd throw it out there. > > Naming backends after "famous runtimes" as in marathons and other road races, > .... except those just end up being named after places or people. Might as > well use the name or home-town of the person who wrote the first line of code > in whatever backend it is. > > Personally, I find separating them into backend scala, vs. backend > c-generator works fine, and if it splits below that, numbering will be > sufficient. > > My summary: > > daffodil > backend-scala-schema-compiler > core-schema-compiler > backend-c-generator-schema-compiler > lib > backend-scala-parser-lib > backend-scala-unparser-lib > backend-c-lib > tdml-lib > tdml-processor > ..... > > > > > > > On 10/5/20 10:23 AM, Beckerle, Mike wrote: >> +1 from me. >> >> ________________________________ >> From: Interrante, John A (GE Research, US) <inter...@research.ge.com> >> Sent: Monday, October 5, 2020 9:28 AM >> To: dev@daffodil.apache.org <dev@daffodil.apache.org> >> Subject: Subproject names proposed for discussion >> >> Steve Lawrence and I would like to bring a topic to the dev list for >> discussion since not everyone is paying attention to the review of my >> runtime2 push request. Steve suggested, and I agree, that renaming some of >> the Daffodil subprojects might make their meanings more obvious to newcomer >> devs. If we do rename some subprojects after discussing it on this list, we >> will do it immediately in its own pull request since mixing changes with >> renames makes it difficult to see which changes are just renames instead of >> actual changes. >> >> What do devs think about us renaming some subprojects like this? >> >> rename daffodil-core to daffodil-schema-compiler >> leave daffodil-lib alone >> rename daffodil-runtime1 to daffodil-backend-parser-scala >> rename daffodil-runtime1-unparser to daffodil-backend-unparser-scala >> rename daffodil-runtime2 to daffodil-backend-generator-c >> >> > > >
