Loading ...
Sorry, an error occurred while loading the content.

Re: [aprsisce] Lua integration with APRSIS

Expand Messages
  • Greg Dolkas
    Hi Lynn, When I think of why I haven t written any APRS-related code, it comes down to not wanting to have to learn the syntax and parsing and general
    Message 1 of 6 , Jun 25, 2012
    • 0 Attachment
      Hi Lynn,

      When I think of why I haven't written any APRS-related code, it comes down to not wanting to have to learn the syntax and parsing and general management of the APRS protocol (and, yes, I'm using that term loosely).  You guys who live and breathe this stuff may not think much of it, but it's a significant barrier to the rest of us, or at least, to me. 

      Where APRSISCE/32 can add a LOT of value is to manage all that stuff.  Give me an interface where I can register to receive certain kinds of packets (specify a filter) or other events (e.g. the infamous MIC-Es), and an interface where I can safely send messages and other basic things (objects, etc.), without having to craft fully formed and syntactly correct packets (*), and I'll fill in the stuff in between.  A presumption of statefullness between calls is in there somewhere, too, and I would be expected to handle any packet I receive from the API in a separate thread, so you aren't blocked by my processing.  If it drop the packet on the floor, oh well, but I would need a way to put the packet back into your processing pipe for display and such.  Also anything I generate. 

      Yeah, this is getting complicated, but if that's what you mean by the first method, then that's probably my choice.

      Greg  KO6TH

      (*)  I suppose supplying a library of Lua routines to do the packet formatting could substitute or augment some of this formatting work...  Just don't make me write them (please).

      p.s. I have absolutely no idea what the plug-in API in UI-View looks like.

      On Mon, Jun 25, 2012 at 6:01 AM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:

      Precisely why it isn't in there already. I'm leaning towards two methods.

      One is a Lua extension callback where certain events within APRSISCE/32
      invoke configured Lua scripts with a documented interface and said Lua
      script is expected to assist with various internal decisions. These are
      the risky ones as they can shut down my client code.

      The second is Lua free-running scripts. These scripts will each have
      their own thread and their own environment. They'll have access to the
      internal station information and whatnot of APRSISCE/32, but they will
      not have the ability to block the client's execution nor directly affect
      that execution.

      This latter class of script strikes me as closest to the UI-View plug-in
      approach, but I'm not really sure as I haven't studied that actual
      interface. But I think most of the useful scripts will fall into this
      class. I just haven't figured out a safe, non-resource-intensive way to
      notify said free-running scripts when stations update and/or provide
      them access to the feed of packets.

      Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

      PS. Apparently the gaming community has adopted Lua scripting to a high
      degree. In my case, the licensing is right - free to do anything you
      want with it!

      On 6/25/2012 2:41 AM, Greg D wrote:
      > Hi Lynn,
      > I've started reading up on Lua, and it's an interesting language. But,
      > what is the model for integrating a programming language with another
      > program, such as APRSISCE/32? Who drives who? Are there events that
      > kick off an Lua thread (e.g. detecting a new station), or is the Lua
      > program running in parallel with APRSIS, polling it for things to do?
      > Just curious,
      > Greg KO6TH
      > ------------------------------------
      > Yahoo! Groups Links

    Your message has been successfully submitted and would be delivered to recipients shortly.