Blog Entry

Submitted by Flyingguy (not verified) on 13 April 2006 - 7:37pm.

Ya know what, you had a good thing going with NWAdmin, then ya screwed it up with ConsoleOne, then ya REALLY screwed it up with iMangler.

NWAdmin, is a good program, nice interface, and it workds well.

Who cares how many plugins you need! When the program loads it links in the most common Plugins, after that they are on demand. You wanna do Zen works? Pardon me while I load the pluggin(s) very quickly.

Everything that is done to the server, edir, Zen, GW, all of them, should have a client server style interface and it should work like this:

1. Pluggin X is activated, it goes to a well known port for the particular component it handles. It says in essence, "Hey there, here I am, this is the numerical version ID I have, is yours different? If yes, then send me your schema so I can re-configure and be prepared to edit your data." After that, it should work just like sql:

update edir set password.user.container.tree = newpassword where user.container.tree = 'fred'

return the result.

Same for GW:

update GW set password.user.postoffice.domain.container.tree = newpassword where user.postoffice.domain.container.tree = 'fred'

Another example:

update edir set purgeimmediate.folder.volume.server.container.tree = true
folder.volume.server.container.tree = 'public.sys'

Populate the list of objects in the tree representation the exact same way with a series of statements that return the names of each oject, heck you could even have it pre-compiled and call it DscribeTree(StartingObject)

But why what do I know.

Submitted by Mike Brady (not verified) on 14 April 2006 - 6:56pm.

I will try to draw this up when I get a chance, but for now you will just have to picture what I am describing.

OK, we all would like a nice browser based management tool. Why Novell keeps insisting on falling back to requiring Internet Explorer for certain features escapes me. We are now in a cross platform world. A world where I think many, if not most, IT folks use FireFox. Since Firefox is available on Windows, Linux and Mac - why not use it as a framework for doing web based admin? There could be a "Novell Management Plugin or Extension" for Firefox. This could extend Firefox in whatever way is needed to properly manage our networks. RedBack Systems has a GroupWise client that does this. Since FireFox is an free/open source product, Novell could easily bundle an installer with the proper extension/plugins. Also, we would be able to easily add additional funtionality via new extensions. Novell could/should offer these extensions via the web, so I could just browse the list of Management plugins and click "install" like I do now with the hundreds of FireFox plugins available. Of course, this reliance on extensions does create a potential problem: you would not be able to sit at just ANY machine and manage your network, the extensions would be needed. Maybe the basic stuff could be done without any extensions like it is now. The more complex stuff, like ZEN, GroupWise, etc... would use extensions.

Submitted by Flyingguy (not verified) on 20 April 2006 - 4:12pm.

Arrrrg, yeah, individual deptartments creating their own snappins and you end up in the Novell equivlient of DLL Hell. These things are big and bulky and they take DAYS to load. If you have every looked at the GW Object ABI for early binding you know what I mean.

This would be SOOOO easy to write. I was driving today and put the thing together in my head!

Create a basic MDI frame. In Delphi you can compile this for window or Linux and you can do the same is GCC. A text file ( schema ) can define the Form and fields on the form ( NOT html ), and each component has a defination. The only thing that needs to be build in are the eDir read and write methods.

The Text file can Be XML, Field Value Pairs ( ala INI style] or whatever. The key here is that the actualy shell is only changes when the eDir read and write methods are changed, everything else is a text file, that simply defines the input page. Now these can be updated painlessly because:

- They are small

- They dont need to be re-installed at the system level

- You get the full cpaabilities of the GUI you are compiling for versus the broken half baked abilities of a web browser.

The standard win32 API, the Gnome API, The AQUA API both work great for this, they have all the pull down, edit, masked edit, checkbox, radio box stuff you could want.

Each field defintion would include the assoiated eDir schmea object, so that when it came time to either read or write to edir the read and write functions would simply work. No more memory conflicts because each one is a DLL and gets packed into a seperate memory space and the inherent problems with shared memory and IPC. The core Novell API is there if you have the client.

Instead of having a massive set of GW DLL's simply build the functionality that is in C1 into the back end, ie: Top Down Re-Build, since you can schedule it anyway.