[PMVAdmin-devel] Progress update

[Sam D. <sam...@gm...>]

Ah, yes. Is there a way around calling these functions? Libraries generally
_don't_ call functions in the application. What you might want to consider
is a semi-secure way of giving the plugins limited access to functions (i.e=
.
"managed" access).

The most obvious way to do this to me, is to NOT PASS AROUND OBJECTS

Rather, construct a "table" containing the function's signature, and the
type of parameters it takes. You would then pass this table to the plugin-
it is all of the external functions it is allowed to call.

This is similar to how Qt handles its signal/slots (connect adds the
slot/signal signatures to a table (array of data structures) in memory and
then given the string representing the function name, it looks through the
table of functions and executes the function pointer.

Table 1: Example table

function_name          function_p        function_args1
function_args2
my_function            0x000F0012        char                  int
die_minions            0x13431421        int                   int

This would be interpreted as the function prototypes:
my_function (char, int);
die_minions (int, int);

This would require the plugin to be very up-front about which functions it
wanted access to - i.e. when it was initialised, it returned a list of the
functions it wanted, and then the management console would construct the
function table accordingly.

That is getting kind of ugly though; the management console would need to
have an existing list of all of the functions, which would probably require
a preprocessor to create at compile time - not nice, but could be quite
powerful.

Giving the library pointers to the objects should work too; but might take =
a
bit of trying to get rid of all of the cryptic problems. It is also
dangerous in the sense that every plugin will have the power to corrupt you=
r
configuration nicely.

Another (safer) alternative is to not let the library directly access
management console calls. I cannot really think of where this would need to
happen.

When the list of "objects" in the main window is being populated, it would
be better if the MC just called a function in the plugin which returned wha=
t
it wanted to put into the lists etc.

Along with that approach, you would probably need to take a kind of
"strange" approach to your functions; I suppose you could have them so that
each call they returned the next element, and then when they were finished,
return a null, or a certain error value.

Summary of the three(?) approaches:

   - Table of functions for each plugin; typesafe calling etc.
   - Passing pointers to certain objects - dangerous. Gives plugins full
   and unrestricted control over the objects. If a plugin had a bug, it wou=
ld
   make it entirely possible to nuke your entire PMVAdmin configuration... =
not
   good.
   - Management console calls functions in the plugin, plugins return
   what they want.


Case "Studies" for each of these approaches

Typesafe calling - Qt's signals and slots

Passing entire objects - probably a lot of proprietary programs out there.
(Free software programmers don't use C++ as much :P )

Program calls library function: most programs written.

A combined approach however, would be to do it like PAM does; where the mai=
n
program initialises the operation, and then the library calls a given
"conversation" function to talk to the main program. For PMVAdmin, this is
probably not a very nice method, for the main developers or for plugin
developers.


On 4/18/06, David Goodwin <dgs...@us...> wrote:
>
> Ok, As usual with a long email which I havent thaught about or planned ou=
t
> I probabily repeat myself a number of times. So I guess I should insert a
> warning: "*This article contains way too much information<http://uncyclop=
edia.org/wiki/Nobody_cares>
> .* Absorbing all of it may cause one's head to splode.", or more correctl=
y
> - "This email is way too messy. Attempting to interpret it may cause one'=
s
> head to splode."
>
> If you are unable to understand this email at all (as is entirely likely)
> there is a very short summary at the end.
>
> Currently the script parser is 100% capable of working with script
> libraries - there is just no script command which allows a function in a
> different file to be called.
>
> The function which processes a script function takes two parameters - the
> file name of the script and the function to process. The "call" command
> calls a function within the same script file. When I implement a script
> editor in the management console an additional command (possibly somthing
> like "call-ex" or just a way of providing an additional filename attribut=
e
> for the call command) will be added which will have two attributes - the
> function name and the file name.
>
> So yes, I am aware what a library is. You shouldnt jump to conclusions -
> nowhere did I say that external scripts would not be possible.
>
>
> The same thing can be done for mapped file connections. It is really f'in=
g
> > stupid to hard code all of the mapped drives (etc) for every
> > user/group/whatever that uses them. Most of the time, you have a collec=
tion
> > of common drive mappings, or drive mappings that follow a consistent pa=
ttern
> > (i.e. P to \\server\(username_here)$ for mapping personal directories).
> > It is stupid, utterly stupid to have every user contain their own code =
to
> > map their personal directories; if for some reason (e.g hard disk
> > failure) the personal directories had to be moved onto a different serv=
er,
> > then *EVERY* user, group, etc would need to be changed. With a script
> > library, you just replace the one function call, and magic, everyone's =
home
> > directory is used.
>
>
> Um, I believe that this is what groups are for. You wouldnt need a script
> library to do this - all you would need to do is open up the appropriate
> group and change the single drive mapping there. No script editing, no
> script libraries, nothing like that. Just one adjustment to one group.
> Ofcourse if someone realy wanted to an external script function could be
> used.
>
> The reason why there are two seperate Management console managed function=
s
> in the script is simply because i dont have to sort out the stuff then.
> Having two managed functions rather than one isnt realy a problem as very
> few people will ever see either of them. Most people will ever see one of
> the functions - MAIN.
>
>
> As I believe I stated earlier I dont currently plan for the first version=
s
> of the management console to last long. Infact I have been slowly working=
 on
> various parts of Version 2.0 of the management console over the past
> little while.
>
> Management Console 2.0 is currently capable of doing the following:
>
>    - Loading configuration data from MConsole2.ini
>    - Applying style settings
>    - Loading and initialising all standard plugins specified in the
>    configuration file
>
> I am currently working on the following:
>
>    - Trying to find a way of allowing a plugin to call functions in the
>    management console
>
> At the moment version 2.0's code is a lot tidier than version 1.0s code a=
s
> version 2.0 is now being written from scratch and currently only has abou=
t
> 5 lines of code in common with version 1.0 (the code that applies style
> settings). There is currently no GUI however - configuration files must b=
e
> edited with a seperate settings-editor program and the plugin interface o=
nly
> has a few functions to do with startup and initialisation.
>
> At anyrate, PMVAdmin 1.0 realy is just an an 'experiment' if you will. It
> is the very first program I have ever written in Qt and it is by far the
> largest program I have ever written in C++. As a result there are a numbe=
r
> of decisions that I now regret in version 1.0 but would take too much
> effort to change. Now that I have a bit more experience with Qt and C++ I=
 am
> being somewhat more careful when designing version 2.0 and I am attemptin=
g
> to avoid the mistakes I made in version 1.0 .
>
> MC2.x will be part of PMVAdmin 2.0. It, however, is not the only part of
> PMVAdmin2. Rather than having MC2 just sitting arround mostly finished do=
ing
> nothing for a few months until PMVAdmin2 is finished it might replace the
> first version of the Management console in latter versions of PMVAdmin 1.=
x.
> This is because version 2.0 should be much easier to maintain and upgrade
> than the current hard-coded version 1.0.
>
>
> SO, there isnt realy much point in arguing much about version 1.0 of the
> Management Console as I will probabily replace it fairly soon after its
> finished.
>
> The reasons why I want to replace Management Console 1.0 quickly:
>
>    - Its not nice to develop - everything is hard coded and the code is
>    becoming quite messy.
>    - It is difficult to add new features to
>    - It is difficult to change how 'objects'
>    (users/groups/workstations/zones) are stored
>    - It is difficult to debug
>
> Management Console 2.0's plugin architecture should fix most of these
> problems as it should provide:
>
>    - A standard way of accessing data regardless of how/where it is
>    stored. This should eliminate the millions of embedded loops and
>    if-statements present in version 1.0's functions that read data out
>    of the XML files.
>    - A standard nice way of accessing configuration data using Qt's
>    QSettings class. Currently this class isnt being used to its full pote=
ntial
>    (user specific and system wide settings, native configuration formats,=
 etc)
>    but that will change when there is a nice UI provided to adjust these
>    settings. At the current stage of development it is easier if the sett=
ings
>    are just restricted to being stored in " MConsole2.ini" as I can
>    easily edit that by hand.
>    - A standard way of adding support for additional object types (such
>    as a server object which allows for the configuration of a server, etc=
).
>    - An easy way to provide new features - just replace a plugin with a
>    newer version
>    - An easy way to provide new data storage options through the use of
>    a data access component.
>    - The actual program should be fully compatible with windows, linux
>    and possibly MacOS X platforms. If there is any platform specific code=
 at
>    all it would be in somthing like the data access component.
>
>
>
> Currently I plan to continue developing the following applications
> simultaneously over the next few weeks:
>
>    - PMVAdmin Management Console version 1.0 (designed for WindowsNT)
>    - PMVAdmin Login Client for WindowsNT version 1.0
>    - PMV Management Console 2.0 (PMC2) (designed to work on both
>    Windows and Linux)
>    - PMC2 Dummy standard plugin (for testing plugin interfaces, etc)
>    - PMC2 Dummy Data Access Component (for testing plugin interfaces,
>    etc)
>
> Once the first two can be considered of "alpha" quality I will make both
> binary and (for anyone crazy enough to want to see it) source available t=
o
> the public. The alpha version should be fully functional but may have a
> number of bugs and probabily wont be as nice to use as it could be (such
> usability problems would be fixed if I have enough time).
>
> Once PMC2 is of alpha quality I will probabily start developing the
> following plugins:
>
>    - A Data Access Component capable of reading PMVAdmin 1.0user/group/wo=
rkstation/zone files
>    - A Standard Plugin capable of managing user objects
>    - A Standard Plugin capable of managing group objects
>    - A Standard Plugin capable of managing workstation objects
>    - A Standard Plugin capable of managing zone objects.
>
> Once these plugins are of alpha quality then PMC2.0 should be fully
> capable of taking over PMVAdmin Management Console 1.0's job. At this
> point PMVAdmin Management Console 1.0's development will probabily slow t=
o
> a halt. For a time PMVAdmin 1.x releases might come with both but
> Management Console 1.0 would eventualy be dropped and all further release=
s
> would use version 2.0.
>
> So, now for the short summary:
>
>    - Script libraries are already very nearly possible - just about 3
>    lines of code away from fully functional
>    - Groups & Zones can provide an acceptable alternative to external
>    script functions in times where only one group/zone needs to do that c=
ertain
>    task (such as mapping home directories).
>    - Management Console 1.0 is my very first Qt application
>    - Management Console 1.0 is by far the largest C++ application ive
>    ever written
>    - There are a number of design decisions that I now regret in
>    version 1.0 which will be corrected in 2.0
>    - Management Console 1.0 has many mistakes that I hope to correct in
>    PMV Management Console 2.0
>    - Management Console 1.0's code is very messy and unflexable
>    - Management Console 1.0 is hard to maintain, expand and debug
>    - PMC2 =3D=3D PMV Management Console 2.x series
>    - MC1 =3D PMVAdmin Management Console 1.x series
>    - Management Console 2.0 and MC1 are being developed at the same
>    time
>    - Management Console 2.0 is being written completly from scratch and
>    doesnt borrow more than about 5 lines of code from MC1
>    - Management Console 2.0 uses plugins to do everything.
>    - Plugins can be replaced without recompiling - all thats required
>    is an adjustment to a configuration file and an applicaiton restart.
>    - Management Console 2.0 should work on Windows, Linux and perhaps
>    MacOS X
>    - Management Console 1.0 would probabily work on linux but it might
>    need a few slight adjustments in some places with respect to directory
>    scanning.
>    - Management Console 2.0 and Management Console 1.0 should hit alpha
>    stage at about the same stage
>    - Management Console 2.0 will fully replace Management Console 1.0in P=
MVAdmin
>    2.0 and most likely in latter releases of PMVAdmin 1.x
>    - Management Console 2.0 is being fully documented as it is written
>    (unlike 1.0).
>
> And that is about as much as I can be bothered explaining right now.
>
> And as a last note, If you have any suggestions on the following it would
> be much appreciated:
>
> I am currently trying to find a way of allowing a plugin to call function=
s
> in the actual management console application. These functions need to tak=
e
> parameters and return values. I made an attempt at passing in a pointer t=
o
> the current instance of the MConsole class (what contains the functions I
> want to make available to the plugin) to the plugin but that just generat=
ed
> cryptic errors that I couldnt manage to fix. So I tried passing a pointer=
 to
> the MConsole instance as a QObject and then  attempting to cast it back t=
o
> an MConsole inside the plugin but that didnt get me much further. Passing
> arround instances of the MConsole class also isnt an ideal solution -
> signals/slots might work but I dont know how I could find out what plugin
> raised the signal. Any ideas?
>
> --
> -David Goodwin
> Email: dgs...@gm...
>