Re: [aprsisce] Lua integration with APRSIS
- 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.
(*) 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
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