Re: Continue Eclipse Freemarker DLTK?

I say, the DebuggerService API and everything around is quite messy.
We should clean it up. I suspect that DebuggerService shouldn't be a
public API at all, let alone be used implementing debugger protocols
with it. For someone who wans to implement a debugging protocol (like
DBGP), the only interesting interface should be `Debugger` and the
interfaces used as method parameters and return values in that.

My idea is this:

- On the client side (Eclipse), you should implement `Debugger` so that
  it translates the calls to DBGP protocol with which it communicates
  with the server. Let's call this class the DBGPDebuggerClient.

- On the server-side (Web application), you need another class, which
  will have a singleton instance, that will listen on some port,
  communicating with DBGP protocol. This has a similar role than what
  you have intended for DebuggerService, and it's also instantiated by
  FreeMarker based on a system property (unless it was already set
  with static `Environment.setDebuggerServer()`). But it doesn't
  extend or implement any FreeMarker classes or interfaces. Its only
  public interface is the DBGP protocol via network. Let's call this
  class the DBGPDebuggerServer. Again, it does not implement
  `Debugger` or anything.

- FreeMarker should create another singleton, of a non-public class
  (that resides in freemarker.core) that implements `Debugger`. This
  singleton is non-configurable and non-replaceable, and only usable
  for debugging with Java API calls within the same JVM. This is the
  piece that actually implements debugging, communicating with the
  core, receiving callback from it, maintaining the map of
  break-points, all the dirty work. (So this has a similar role to
  `DebuggerService.instance` in 2.3.20 and earlier; note how that
  wasn't configurable/replaceable either, apart from disabling it)
  This singleton should be obtainable via the static method
  `Environment.getDebugger()`.

When DBGPDebuggerServer receives a "call" in DBGP protocol, it calls
the methods of the `Debugger` returned by `Environment.getDebugger()`,
and that's it. So it only deals with translation between the DBGP
protocol and the `Debugger` API.

Similarly, we could have a RMIDebuggerServer that's basically what
`DebuggerServer` is now (it should be renamed), and just like
DBGPDebuggerServer, it wouldn't extend/implement any particular class
or interface. It would just delegate to
LocalDebuggerServer.getInstance() though the object that it sends back
via serialization (just like now).

To sum it up:

- The only public debugger API is `Debugger`, and the interfaces used
  in the signature of its method.

- To implement a debugger protocol Xxx, you create two classes, neither is
  expected to extend/implement any particular interface or class:

  . `XxxDebuggerClient`, whose instantiation is the business of the
    client (like an IDE plugin)

  . `XxxDebuggerServer`, whose instantiation is done by FreeMarker,
     based on the system property (`freemarker.debug.debuggerServer`),
     unless it was already set with static
     Environment.setDebuggerServer(). `XxxDebuggerServer`, after
     translating from/to Xxx, delegates to
     `LocalDebuggerServer.getInstance()`.

-- 
Thanks,
 Daniel Dekany


------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk