It's been incredible to watch what people like czechboy have done with ecaradec's indescribably cool FScript plugin DLL for FARR, that allows people to write plugins for FARR using javascript.
Indeed i am still completely amazed at what ecaradec created.
And then watching how czechboy ran with the concept and just kept making more and better plugins.. i'm speechless.
It's only the amazingness of ecaradec's Fscript that makes one think about other possibilities.
This post is meant to start a thread for us to discuss the possibility of a higher-level fscript interface that would work with multiple javascript (python script, etc) addon scripts, without them needing to each have their own DLL.
This idea has come up before but was dismissed because of difficulties and because it wasn't clear how exactly it should work.
I'd like to revive the discussion and see if we can't perhaps beg/encourage ecaradec to consider actually taking a second look at this idea.
Just to summarize the advantages and the basic approach, it is this:
Currently to write a plugin for FARR using javascript you would create a new plugin project, copy the basic fscript.dll into it, and implement some basic functionalities, and then load it into FARR as an independent plugin.
The new idea would use one single plugin DLL for fscript that was loaded into FARR. This multi-fscript plugin would then itself manage a whole subdirectory of simple fscript-based plugins.
Such plugin fscripts would therefore be easier to write, could share some javascript core functions, and would be easier for people to write and test and share. And it would avoid having to have 10 DLLs loaded if you have 10 traditional fscript-based plugins.
I think such an approach would also open up the door for some
dqsd like multi-plugin systems. Once a multi-fscript plugin system was written it wouldnt be hard to make some shared javascript code that could provide a dqsd-like api for user scripts -- making it even EASIER for novices to write new plugin scripts.
Recent Posts
