New Release: ElectroServer 3.6.6

[webgeek]

Hi al! We are proud to announce a new release to the server, putting us to version in 3.6.6. You can snag it off the downloads page. The big new feature is one that I know you have all been waiting for... Web-based administration :) Personally, we feel it's pretty self-explanatory and should be simple for you to use. Please give it a shot and let us know if you run into any issues. We are certain that some bugs are still lurking around and will try to fix them as soon as you report them. We will be releasing another update in a few days that contains the event handler examples. Thanks!

[Argiris]

We just got it! It looks great (nice design!) and we're about to give it a try!

Good job, guys! ;)

[peterblaze]

Hi guys,

I've just tested admin section and works great :yeah:
impressed,
also works well when exported to standalone desktop application,

one minor problem: not scalling within FireFox browser (there is a problem with that)
http://chattyfig.figleaf.com/ezmlm/ezmlm-cgi?1:sss:126168:200411:jocmobmbjmilfcbdkjia#b

nice job,

regards,
Peter

[Argiris]

Mike, I already told you about my suggestion for a message being broadcasted to all connected clients prior to the server restart.
Another addition which should be easy to implement, but would add a lot to the functionality is adding a "Currently online users" section somewhere in the remote admin panel, so the administrator can see how many people are online, before performing the restart.

If you want to push that a bit further, you could make an online user handler (kick user off server, ban user, etc) by right clicking on the user's name and selecting what you want to do with them.

Finally, I think you should either release the FLA file or make the admin panel's texts coming from an XML file for Internationalization purposes.

Thanks!

[Argiris]

Another upgrade which could help resolve many issues, is when there's an exception, instead of it only being written in the logs, it will also fire an event (like onException) which will contain the message of the error.

That could help debugging of complicated applications, such as ours, because we could get bug reports from our own users accompanied by technical terms instead of a meaningless "Suddenly everything started flashing".

We could capture the event, get the message, display it to the user and ask them to report it along with what happened to cause that (what they saw).

Looking over the logs (which can be bit cryptic, by the way) can't help a lot if you don't know the circumstances that caused an error.