You can subscribe to this list here.
2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|
From: David G. <dgs...@us...> - 2006-04-19 06:08:06
|
On 4/19/06, Sam Douglas <sam...@gm...> wrote: > > 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). > A way arround? Ive been trying to think of a way of avoiding it for a while now but I dont think it would realy be properly possible. The plugin needs to call functions in the management console to perform the following actions: - Loading its configuration data - Saving its configuration data - Recieving data from the storage services - Sending data to the storage services 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. > Yes, I considered this but at this stage I have no experience with such things. I have seen it done however - WinLogin provides a GINA component with a table of functions it can call in winlogon. 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 an= d > then given the string representing the function name, it looks through th= e > 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 i= t > wanted access to - i.e. when it was initialised, it returned a list of th= e > functions it wanted, and then the management console would construct the > function table accordingly. > Probabily not much need for this. At the moment I can only think of about four functions that would need to be made available to the plugins and most plugins would make use of them. 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 requi= re > 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 tak= e > 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 y= our > configuration nicely. > About the only danger is that a plugin might try to delete the management console object. It couldnt mess with anything else however. Right now the only public members of the class are the four mentioned functions, the constructor and the destructor. 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 woul= d > be better if the MC just called a function in the plugin which returned w= hat > it wanted to put into the lists etc. > That is what it is currently setup to do. About the only time when a plugin needs to call functions in the MC is when it is loading and saving data (either from MCs settings file or from the data access component) 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 th= at > each call they returned the next element, and then when they were finishe= d, > 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 > would 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 > main program initialises the operation, and then the library calls a give= n > "conversation" function to talk to the main program. For PMVAdmin, this i= s > probably not a very nice method, for the main developers or for plugin > developers. > Currently i have no idea what the errors that MinGW is throwing back at me mean so I might look into function tables... -- -David Goodwin Email: dgs...@gm... |
From: Sam D. <sam...@gm...> - 2006-04-19 00:58:46
|
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... > |
From: David G. <dgs...@us...> - 2006-04-18 05:16:31
|
Ok, As usual with a long email which I havent thaught about or planned out = I probabily repeat myself a number of times. So I guess I should insert a warning: "*This article contains way too much information<http://uncyclopedia.org/wiki/Nobody_cares> .* Absorbing all of it may cause one's head to splode.", or more correctly = - "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 librarie= s - 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 attribute 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'ing > 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 collecti= on > of common drive mappings, or drive mappings that follow a consistent patt= ern > (i.e. P to \\server\(username_here)$ for mapping personal directories). I= t > is stupid, utterly stupid to have every user contain their own code to ma= p > their personal directories; if for some reason (e.g hard disk failure) th= e > personal directories had to be moved onto a different server, then *EVERY= * > user, group, etc would need to be changed. With a script library, you jus= t > replace the one function call, and magic, everyone's home directory is us= ed. 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 functions 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 versions of the management console to last long. Infact I have been slowly working o= n 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 as version 2.0 is now being written from scratch and currently only has about = 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 be edited with a seperate settings-editor program and the plugin interface onl= y 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 i= s 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 number of decisions that I now regret in version 1.0 but would take too much effor= t 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 attempting 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 doin= g 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 potent= ial (user specific and system wide settings, native configuration formats, e= tc) 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 settin= gs 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 a= t 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 to 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/workstation/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 PMVAdmi= n Management Console 1.0's development will probabily slow to a halt. For a time PMVAdmin 1.x releases might come with both but Management Console 1.0would eventualy be dropped and all further releases 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 cer= tain 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.0 in PMVAdmin 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 b= e much appreciated: I am currently trying to find a way of allowing a plugin to call functions in the actual management console application. These functions need to take parameters and return values. I made an attempt at passing in a pointer to 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 generated cryptic errors that I couldnt manage to fix. So I tried passing a pointer t= o the MConsole instance as a QObject and then attempting to cast it back to 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... |
From: Sam D. <sam...@gm...> - 2006-04-18 02:06:26
|
My feeling on the function thing is still the same; rather than have all of these piles of arbitrarily named functions for each different type of actio= n the management console creates, why not just provide a single function like "PMVAdmin_Auto" which is created by the management console and stores all o= f the management console created code. You seem to be very much concerntratin= g on certain options like the ability to disable the managment console generate script, but are missing the true point of what makes the program more flexible and elegant; like the ease to add new features, or how best t= o handle the UI->login script conversion. Inside this function you would put all of the management console code for the "object" (i.e. user) <function name=3D"PMVAdmin_Auto"> //"Settings" (better term than Policies; more generic and applicable) ... //Network file resources (or a nicer term) ... //Network printers ... //Etcetera </function> This is far more tidy than putting everything into separate functions in th= e script (and then trying to indicate to the management console to look in that function). The order is not important; but it is no harder for the management console to put stuff into a sensible order, and separate it with linebreaks and comments to improve the readability of the scripts. Reading it back into the managment console is, if anything; easier. You parse one function in the script: if (line_is_setting) { //This function goes away and adds a setting given the name, and extracts //necessary meta data if possible/implemented add_setting (setting_name); } else if (line_is_network_file) { //Same as above add_network_file (connection_name); } ... else if (line_is_sobject) { //Add the script object, lookup the object's metadata //An script object is pretty much a reusable function, in a script //library that is accessible to all scripts. add_sobject (sobject_name); } Just as an example. I introduced an important idea there: script libraries. Script libraries ar= e a point which David has seemingly wanted to trim from my original designs for some reason or another, which I am yet to be presented with. Basically, they encourage reusable scripts by creating an abstract way to reference external scripts. Obvious candidates to be put into script libraries are lockdown settings for the various desktop environments that PMVAdmin supports (i.e. a library for Windows Lockdown settings which contains functions to add and remove policies without directly putting the code into the login script); and user made script libraries (such as a library containing functions to map each of the printers on the site. This makes it a lot harder to screw up your setup, and a lot easier to code PMVAdmin. If you say, changed the printer, rather than go through and re-edit *every* single script that uses it, you could change it once in the code library, and then all users/groups/etc that reference the code has now been changed. The same thing can be done for mapped file connections. It is really f'ing 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 collection of common drive mappings, or drive mappings that follow a consistent patter= n (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 server, 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= . I don't know what rock you have just crawled out from under; but don't get the impression that libraries are my idea; they have been around for years and are used extensively in computers. Qt is a library; it does a similar thing to putting login scripts into script libraries; the operating system can be changed, without the code itself being changed; likewise, the librar= y can be changed, without programs that use it having to be changed. If a bug in Qt (or GTK, or gdi.dll or crypto.dll (i.e left debugging symbol= s in and someone finds your secret NSA backdoors :)) is deployed, then applications that dynamically link to it (i.e. just reference the Qt function calls) can be easily fixed by patching the library; one change, on= e recompile. Programs which statically link the library are still affected. Static linking is when the library code is put into the program - i.e. hard coded - by the compiler(linker). Hard coding has the benefit of letting dum= b people/systems work on your program without having to worry about the library; but when it comes time to make changes to the system the whole thing falls over. The exact same thing applies to PMVAdmin. David: remember how long the setu= p account was broken at HHS because of problems creating the login script in PSE?** Those kind of problems can be avoided if you can avoid trying to mak= e another "me-too" program like all of the other ones available. Just because every other program forces everything to be nice and hard to adjust, doesn'= t mean that it is a likable feature and that PMVAdmin should try to replicate it. **For people who are not David; when we were employed by Hillcrest High School a few years ago, the setup account we used for doing some basic admi= n tasks was broken for a very long time, due to a confusing system for settin= g up login scripts and mapped drives and groups. Chance of ever wanting to disable the management console code (manually) fo= r a login script object? Slim to nill. A "user" that has a custom script that needs to override the management console generated code is ridiculous; why waste time cluttering the program with these silly options, all the while ignoring true problems like "What if I want to run the management console off an unmapped location (like I would 90% of the time)?" Anyhow, this is not really intended as a flame... Just a lump of opinionated e-rag. Sam Douglas. The other person who used to be working on PMVAdmin until he undertook a fa= r too ambitious project that nobody really wants to help him on, because he i= s the only one who knows what he is doing; and is in some respects happy to d= o it alone, because some people just have funny ideas about things that conflict with his own funny ideas. On 4/17/06, David Goodwin <dgs...@us...> wrote: > As this is the very first mailing list post I suppose I should quickly > introduce myself for anyone else who may read this in the archives or is > secretly listening in on my emails. I am David Goodwin, the project > administrator, lead developer, etc, on the PMVAdmin project. I am currently > doing a BCMS (Computing and Mathematical Sciences) degree at the university > of Waikato, New Zealand. As a result development tends to slow down when = I > have tests or assignments to do. > > Now for the first publicly available progress update on the PMVAdmin > project. > > PMVAdmin Management Console 1.0 > Currently work is being done to try and get the PMVAdmin Management Console > to a state where it could be considered an alpha version. At that point > binaries and source will be made available to the public. > It is possible that version 1.0 will never see a stable release because > development on the more flexible version 2.0 will begin as soon as versio= n > 1.0 is in an alpha state. At this point both versions will be developed > simultaneously. Bugs will be fixed in 1.0 and new features, etc, will be > added in 2.0. > > Currently version 1.0 is very non-expandable. There is a lot of hard code= d > stuff. This will change in version 2.0 which will provide a plugin > architecture. PMVAdmin Management Console 2.0 will be used in PMVAdmin 2.= 0 > and possibly PMVAdmin 1.0. > > The Management Console version 1.0 is currently capable of the following > things: > > Loading/Saving configuration data > Loading/saving user files > Loading/saving group files > Loading/saving workstation files > Loading/saving zone filesSupport for workstations/zones/groups is fairly > small at this stage but will be expanded quite a lot over the next month or > two depending on how much time I have available. The Management Console > currently has no knowledge of the scripts that can be embedded into those > files - this will be added fairly soon. > > The Management Console is also incapable of being run off a network location > as QFile does not seem to be capable of accessing files addressed using a > UNC pathname. This means that the management console must be run off a > mapped network drive or off local storage. According to Sam cstdio's fope= n > functions are capable of working with UNC pathnames under windows so this > has been used in the client. As the management console makes use of Qts QDir > classes which probably don't support such UNC paths making use of fopen > probably wouldn't help the management console run from a network path. > > At this stage the management console makes no use of the Win32 API. This > means that, in theory, it should compile and run fine on Linux. > > PMVAdmin Login Engine 1.0 > About two days ago I started work on the first version of the login engine. > This program processes login scripts, applies settings and does other suc= h > stuff. After a few hours fighting with the Win32 API the software is now > capable of detecting the currently logged in user and also the workstatio= n > name. I was up until 2AM this morning working on the scripting support an= d > the login engine is now capable of the following: > > Loading the user file for the logged in user > Loading the workstation file for the current workstation > Loading all groups that the user is a member of > Loading all zones that the workstation is a member of > Checking if any of the group or zone accounts are disabled and denying th= e > user login access if any are found to be disabled > Checking if the user or workstation is disabled and denying the user logi= n > access if one of them are found to be disabled > Allowing the user login access automatically if the admin flag is set > regardless of if any of the accounts are set to disabled. This prevents > administrators from accidentally locking themselves out.As far as scripting > support goes, the following has been implemented and is functional: > > Automatic processing of management console controlled functions if auto > attribute is set to true > Automatic processing of main function > same-file function calling (calling of other functions within the current > file) The following scripting commands have been implemented: > > call > print > msgbox > clear > showstat > hidestatan exit command has also been partially implemented but it doesn'= t > work at this stage for some reason. > > At this stage there are still a number of major script commands that have > not yet been implemented. These will probably be implemented sometime ove= r > the next week or two. > > If Sam is correct about fopen working with UNC pathnames under windows then > the login engine should be capable of running off a network location without > any problems. I have not yet tested this however as my Pentium 3 isn't even > getting as far as POST when turned on and I haven't gotten around to fixing > it yet (the CPU has probably just fallen out again). > > As I implement parts of the scripting support I am documenting it. I have > attached a copy of the current documentation in PDF format which you can > look at for more information on what the currently implemented commands d= o > provided that sourceforge doesn't filter it out. This documentation is > purely reference for use while implementing stuff. The format will probably > remain in any final version but the text on functions and a few other bit= s > will likely be rewritten. > > On the note of functions, they don't support parameters and they don't > support returning data. This is currently because the actual scripting > language doesn't support variables and in version 1.0 it probably never will > as it would make it somewhat more complicated to do using nothing more than > an XML parser. > > PMVAdmin version 2.0 might provide support for a more advanced scripting > language for those who want it. This scripting language would use QSA > (QtScript for Applications) which I think supports functions, variables, > etc. If such scripting support were to be implemented in the future the old > one would probably remain for those who just want something simple. > > Anyhow, that is about all the progress I can be bothered commenting on. A= t > this rate i might have an alpha version ready within a month or two so I > will probably provide some more progress updates sometime in the near future > - probably once I have given the management console some form of support for > the scripts. > > Now, as usual with long emails which I haven't planned before this email > might be a bit difficult to understand and might randomly change subjects > without warning in some places. If anything needs clarification then feel > free to email me on or off list. If flaming could be avoided that would b= e > much appreciated. > > -- > -David Goodwin > Email: dgs...@us... > |
From: David G. <dgs...@gm...> - 2006-01-28 22:41:23
|
Testmail : first email to pms...@li... -- -David Goodwin Email: dgs...@gm... |