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... |