Just piling on with another +1 to the idea of splitting the daffodil debugger 
server from the VSCode extension.

The server is more mature / stable versus the heavy development that is 
occurring on the extension. The extension leverages the server as a loosely 
coupled dependency service (using DAP).  Consuming it as a dependency from the 
extension repo will be helpful and is a pattern we're already using for Ωedit 
integration, another loosely coupled dependency service (using gRPC).

I agree with Steve on most of what he's said, though I'm more in the separate 
repo camp because it allows us to independently maintain, develop, test, 
version, and release the debugger service outside of the established daffodil 
development cycle.  There are benefits to developing in layers, and using loose 
coupling between layers.  There are also appreciable downsides to having "yet 
another" daffodil repo that needs to be stood up and maintained.  A positive to 
having it live in the main daffodil repo is also the additional exposure it 
will get.  I recognize that this is additional burden on Mike, Steve, and ASF, 
so I defer out of fairness.

I'm in favor of ""daffodil-debugger ", instead of "daffodil-debugger-scala" as 
I don't think anyone should care about the programming language used to develop 
the server, since DAP is the interface being used, not language bindings.

-Davin

On 7/19/22, 2:16 PM, "Steve Lawrence" <slawre...@apache.org> wrote:

    +1 to this

    I was thinking the same thing as I read this. My only thought is using 
    "daffodil dap" since the debug server is just a thing that implements 
    the DAP protocol, and theoretically it could be used any any IDE that 
    supports DAP (I think?). But the name is the easy part.

    My only other (minor) concern is that this pulls in a number of 
    dependencies. It's not an issue from a licensing perspective since we 
    know they are fine, but it does make the CLI release a bit bigger and 
    more to manage, e.g. lots of Cats jars. I suspect it's not enough to 
    really matter (and most of the size is probably daffodil jars), but if 
    we do go this route, during or prior to migration it might be worth 
    looking to see if anything can be replaced. For example, one thing that 
    jumps out is VSCode debugger currently depends on logback for logging, 
    but daffodil use log4j.

    The other concern is that currently the VS Code stuff can sort of 
    develop at its own pace. If we integrate the DAP portion into the CLI, 
    it means VSCode can't get DAP updates without a Daffodil release. But it 
    seems DAP is fairly stable, and as long as we keep a quick release cycle 
    and plan accordingly, that shouldn't be too much of an issue.

    I would perfer this approach over creating a new repo. It's a bit less 
    to keep track of, and makes it easier to ensure we don't have any 
    breaking changes with changes to Daffodil.

    On 7/19/22 1:52 PM, Mike Beckerle wrote:
    > I think of this as a daffodil server mode, for the front end VSCode stuff
    > to use.
    > 
    > So, is it plausable to add the code to daffodil proper. Make it a CLI
    > command mode to start up this server, so that
    > 
    >      daffodil vscodeServer
    > 
    > starts it, optionally with connection options like what ports to use, etc.
    > 
    > 
    > On Tue, Jul 19, 2022 at 1:45 PM Shane Dell <shaned...@apache.org> wrote:
    > 
    >> All,
    >>
    >> This thread is to discuss splitting out the code for the Apache Daffodil
    >> Scala Debugger from the apache/daffodil-vscode repository. The two 
options
    >> would be:
    >>
    >> - 1.) Move the debugger source code into the apache/daffodil repo. 
However,
    >> will this work because the debugger code depends on certain daffodil 
Scala
    >> libraries to be published? This is mostly an option since both are
    >> mostly/fully Scala based.
    >> - 2.) Create a new repo (apache/daffodil-debugger?,
    >> apache/daffodil-debugger-scala?) where the Scala code will live.
    >>
    >> This would be helpful as the apache/daffodil-vscode repo is heavily based
    >> on creating the VS Code extension for Daffodil. With this the debugger
    >> source code is rarely updated, when it is they are pretty minor fixes or
    >> dependency updates. Currently it is a bit of a cluster having a mix of
    >> node/JavaScript/TypeScript and Scala which causes an issue with 
dependency
    >> bots checking as these are checking for both npm and sbt/Scala
    >> dependencies, causing many PRs to be made. The extension code also runs a
    >> sbt universal:packageBin command in multiple occurences, being able to
    >> remove this and downloading the debugger package would simplify a couple
    >> different processes for the extension.
    >>
    >> My personal vote is for creating a new repo called something like either
    >> apache/daffodil-debugger or apache/daffodil-debugger-scala.
    >>
    >> Sincerely,
    >>
    >> Shane Dell
    >>
    > 



-----------------------------------------------------------------
This message and any files transmitted within are intended
solely for the addressee or its representative and may contain
company proprietary information.  If you are not the intended
recipient, notify the sender immediately and delete this
message.  Publication, reproduction, forwarding, or content
disclosure is prohibited without the consent of the original
sender and may be unlawful.

Concurrent Technologies Corporation and its Affiliates.
www.ctc.com  1-800-282-4392
-----------------------------------------------------------------

Reply via email to