stevedlawrence commented on a change in pull request #422: URL: https://github.com/apache/incubator-daffodil/pull/422#discussion_r499590947
########## File path: daffodil-core/src/main/scala/org/apache/daffodil/runtime2/Runtime2DataProcessor.scala ########## @@ -0,0 +1,211 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.daffodil.runtime2 + +import java.io.File +import java.io.InputStream +import java.io.OutputStream + +import org.apache.daffodil.api.DFDL +import org.apache.daffodil.api.DaffodilTunables +import org.apache.daffodil.api.DataLocation +import org.apache.daffodil.api.ValidationMode +import org.apache.daffodil.externalvars.Binding +import org.apache.daffodil.processors.Failure +import org.apache.daffodil.processors.ProcessorResult +import org.apache.daffodil.processors.Success +import org.apache.daffodil.processors.VariableMap +import org.apache.daffodil.processors.WithDiagnosticsImpl +import org.apache.daffodil.processors.parsers.ParseError +import org.apache.daffodil.processors.unparsers.UnparseError +import org.apache.daffodil.util.Maybe +import org.apache.daffodil.util.Maybe.Nope +import os.Pipe + +/** + * Effectively a scala proxy object that does its work via the underlying C-code. + * Will need to consider how to use features of underlying C-code to get infoset, + * walk infoset, generate XML for use by TDML tests. + */ +class Runtime2DataProcessor(executableFile: os.Path) extends DFDL.DataProcessorBase { + /** + * Returns a data processor with all the same state, but the validation mode changed to that of the argument. + * + * Note that the default validation mode is "off", that is, no validation is performed. + */ + override def withValidationMode(mode: ValidationMode.Type): DFDL.DataProcessor = ??? + + override def withTunable(name: String, value: String): DFDL.DataProcessor = ??? + + override def withTunables(tunables: Map[String, String]): DFDL.DataProcessor = ??? + + override def withExternalVariables(extVars: Map[String, String]): DFDL.DataProcessor = ??? + + override def withExternalVariables(extVars: File): DFDL.DataProcessor = ??? + + override def withExternalVariables(extVars: Seq[Binding]): DFDL.DataProcessor = ??? + + override def validationMode: ValidationMode.Type = ??? + + override def getTunables(): DaffodilTunables = ??? + + override def save(output: DFDL.Output): Unit = ??? + + override def variableMap: VariableMap = ??? + + override def setValidationMode(mode: ValidationMode.Type): Unit = ??? + + override def setExternalVariables(extVars: Map[String, String]): Unit = ??? + + override def setExternalVariables(extVars: File): Unit = ??? + + override def setExternalVariables(extVars: File, tunable: DaffodilTunables): Unit = ??? + + override def setExternalVariables(extVars: Seq[Binding]): Unit = ??? + + override def setTunable(tunable: String, value: String): Unit = ??? + + override def setTunables(tunables: Map[String, String]): Unit = ??? + + /** + * Returns an object which contains the result, and/or diagnostic information. + */ + def parse(input: InputStream): ParseResult = { Review comment: A separate subcommand such as generate doesn'ts seem unreasonable. Though, I can imagine that if we ended up with another runtime that generated something else (eg. python, java, vhdl) that the generate command would take very different options, which could cause confusion. Have a separate command per runtime solves this, but I think maybe makes usability a bit harder, especially since the backend names aren't very obvious (runtime1) when compared to "parse/unparse". Maybe the best option is to just make our CLI runtime1 focused as Mike suggestes, but then we still need a way to execute runtime2. Maybe it's a separate CLI tool with a completely different name, and all new runtimes will get a unique CLI. This too might be worth a larger discussion on the dev list. How are people expected to use and trigger different backends ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
