Re: Looking for Documentation: Plugin Architecture -- RPG400-L

I will be starting a new project here soon and want to start learning what I
need to this project. I want to create a more plug-in based architecture for
this program where a main "processing program" calls the correct plug-in to
do the actual processing.

Man, an example would sure help me understand what you're trying to do.Let me describe something, and maybe it'll fit what you're trying to do :)

a) Have a file that contains a library name and service program name, aswell as a key for the criteria under which it should use the plugin. Youcan use another means of looking up the "right driver" as well, how youlook it up is really immaterial.

b) When your program initializes (but hopefully NOT during runtime, forperformance reasons) it should activate the specified service program, andcall a init_plugin() (or whatever name you like) subprocedure in thatservice program.

That plugin would accept a standard data structure as a parameter, and inthat data structure would be procedure pointers for every routine that youneed to call in your "plugin".


c) During execution, you make calls using the procedure pointers.

Does that make sense? I'm finding it hard to explain without actuallyshowing you code -- and it'd take me a long time to reply if I wrote code;)

I've done something similar to this in HTTPAPI. I have a "CommunicationDriver" setup where I "plugin" the SSL driver when an SSL connection isrequired, or a normal TCP driver otherwise.

Each driver is a separate module, but they have the same routines, exceptfor the names.


One module has
CommTCP_New(), CommTCP_Connect(), CommTCP_Read(), etc

the other has
CommSSL_New(), CommSSL_Connect(), CommSSL_Read(), and so on...

When the main HTTPAPI routine is processing a request, it checks to seewhat the requested URL starts with. The code looks something like this (Idon't have it in front of me)


select;
when peCommType='https';
   p_CommDriver = %paddr(CommSSL_New);
other;
   p_CommDriver = %paddr(CommTCP_New);
endsl;


Then, there's a data structure based on p_CommDriver:

     D p_CommDriver    s               *   inz(*NULL)
     D commDriver      ds                  based(p_CommDriver)
     D    p_CommConnect...
     D                                 *   procptr
     D    p_CommRead...
     D                                 *   procptr
     D    p_CommBlockRead...
     D                                 *   procptr

And there's prototypes for each pointer in the data structure:

     D comm_Connect...
     D                 PR             1N   extproc(p_CommConnect)
     D   handle                        *   value
     D   AddrInfo                      *   value
     D   timeout                     10P 3 value

     D comm_Read...
     D                 PR            10I 0 extproc(p_CommRead)
     D   handle                        *   value
     D   buffer                        *   value
     D   bufsize                     10I 0 value
     D   timeout                     10P 3 value

When the main program wants to connect, or read, or whatever, it calls

comm_Connect() or comm_Read(). They, in turn, call the routines thatCommTCP_New() or CommSSL_New() set those pointers to.


Does that make sense?

If I did it over again, though, I'd do it a little differently. Instead,I'd do the following:

a) Instead of using static modules, I'd use separate service prgorams.That way, a new one can be installed without any re-compilng or binding.

b) have "http" and "https" as keys to a file. In the file, have fieldsfor the service program name and library.

c) Use the QleActBndPgm() and QleGetExport() APIs to get a pointer to the"init_driver" routine of the service program that I want to use. I'dstill have the service program fill-in a data structure with all of theprocedure pointers, though. That should be faster than callingQleGetExport() repeatedly, plus it puts the decision making into thedriver's code rahter than the mainline, which I think is smart.

That way, if someone wanted to add another driver, all he'd have to do iswrite a service program and update the file to register it with thesystem.

While I am not sure of the proper way to do this, I am thinking of having a
file with the condition and the subprocedure to call. When the condition is
hit, the subprocedure it is associated with is called. I would prefer to use
a subprocedure for this. Would call-backs work with something like this? How
do you do call-backs?

You could do callbacks the same way. Usually with a callback you pass theprocedure pointer as a parameter instead of having one that's initializedonce and then reused for the duration of the program, but it's more orless the same thing.

Whether a "driver structure" or a "callback" is more appropriate reallydepends on what your application does and how it works. Are you writing atool that is to be called from other programs? If so, a callback mightmake more sense.

Are you writing something where someone can "download a module and installit" (without doing any programming) and then it'll "just work"? If so, adriver-type structure would probably make more sense.


Anyway, i've got an appointment to keep, so I've gotta run.