Zugg Software :: View topic

Posted: Sat Mar 20, 2004 4:35 am

OK, I've got a decision to make:

1) I can just use the MS Scripting Engine as I've talked about and as I've done in zMUD. This would let you create a script (for a button, for example) in any language supported by the Scripting Engine (default is VBScript and JScript). But there would be no "development" environment...you just enter your script as plain text into a multi-line text box and thats it...no syntax checking, no debugger, etc.

2) TMS Software produces a component for Delphi for Scripting support. Actually, they produce a LOT of very high quality Delphi components. I'll already be using their Planner/Calendar components for example. Anyway, their scripting components allow you to write scripts in "Pascal" or "Basic". Pascal is Delphi syntax compatible, and Basic is VBScript compatible. This is a *rich* scripting interpreter that supports compiled scripts for speed, full COM access, etc. Also, it includes a syntax editor and debugger. I've played with the demos and these are NICE components. They are what I dreamed the syntax editor in zMUD could be like but are much better.

Obviously, the downside to (2) is lack of support for any other scripting language, such as JScript or Perl. Since (1) is so easy to implement, I could maybe even to both (somewhat like I did in zMUD) where the "native" scripts use the Scripting component and are in Pascal or Basic, and then allow you to use MS Scripting Engine scripts without any additional support.

Comments or Suggestions? Playing with their scripting demo has gotten me very excited. Using their components is going to produce a very impressive application with very little work. I wish I had access to these components back when I was designing zMUD! Also, their components are very inexpensive. Definitely a company to look into if you are writing Delphi code.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

I'd take 2, especially if it had a compiler as part of it. If 2's compatible with C++Builder then I might make work buy me a copy to embed in our appz too.

Posted: Sat Mar 20, 2004 7:50 am

I gotta agree with Rainchild, #2 would definately be more of a benefit to me.

Enchanter Joined: 10 Oct 2000 Posts: 656 Location: USA

#1 for me. I have not used pascal in ages and have no plans of relearning it.

a little off topic, i was wondering how you are going to impliment regex or trigger parsing. Are you going to have similar commands like zmud so we won't have to learn new parsing syntax, or will you go strickly with regex syntax. Also will the regex be parsed for the entire email, or a line by line parsing within the email. I think both have its advantages.

Posted: Sun Mar 21, 2004 8:22 am

ZuggMail will have two ways to do filtering rules:

1) Wizard based, like in Outlook, where you select the kind of conditions like "Subject contains words" and string the conditions together and then choose a set of actions.

2) Regular expression filters will use the same PCRE library used in the 7.0 version of zMUD. That is the ONLY pattern language that will be used. There will not be anything like zMUD triggers, just regular expressions. You *will* be able to use subpattern capture in order to use captured text in your script.

For RegEx filters, you'll be able to specify either a specific "field" or "header" to trigger on, or you will also be able to run a RegEx using the entire untouched message, as well as the entire message after running it through an HTML cleanup/strip routine. So, lots of possibilities.

RegEx filters are, by their very nature, line by line triggers. Think of using "grep" on the unix command line for example...that applies a regular expression to each line in a file. This will work the same way. You can use n in the regular expression pattern for multiline triggers just like in perl or zMUD.

Magician Joined: 09 Oct 2003 Posts: 459 Location: USA

I personally would like a combo of 1 and 2. I could use 1 until I remember more pascal and then just switch over to 2. Also, you might check with TMS to see if they are going to release/support any other scripting types like Perl, jscript, or even PHP (hey, I can dream).

Posted: Tue Mar 23, 2004 10:34 pm

Just in case it wasn't clear, option (2) includes BOTH Pascal AND Basic (VBScript). I'll check to see what the plans of TMS are, but I doubt they are working on anything else in that area. The only one I could forsee enough interest in is JavaScript. They did Pascal/Delphi because of their customer market (all Delphi programmers) and did Basic for the rest of the people who want VBScript. VBScript is the most common scripting language used in Windows. So, they've covered the most popular amoung general users, along with the most popular amoung their customer base. The next most popular would be JScript. They *do* have a syntax editor that handles all sorts of languages, but it doesn't execute scripts, just does syntax checking. But I might use that in conjunction with the MS Scripting Engine. All you'd lose then is the compiled script for speed and the debugger.

Anyway, I think a combination approach is what I'll probably do, assuming that their Basic support is compatible with VBScript after testing and that the component is fast and not too much of a resource hog.

Magician Joined: 13 Oct 2000 Posts: 463

I'd have to say that your choice here is a lot less important than the amount of time and effort put into making the API you expose to the script easy to use. A good API is all that matters to the end user... clear, understandible, and easy to use.

What compiler you choose is completely secondary. I'd lean towards #1, because that would give you more time to work on making the API better, and it's free. I really don't think the benefits of #2 are worth the likely cost, both in time and in money.

You may dislike .NET because you distrust MS... hell, I don't trust MS either. But .NET has one wonderful thing... an API and an object model that is FUN to use. The Object model is nearly self documenting. That matters more than any other decision you make with your scripting... a good object model.

IMO

Raven

Site Admin Joined: 29 Sep 2000 Posts: 389 Location: USA

Yes, but that's obvious. Of course the API needs to be easy to use, complete, well documented, etc. That goes without saying and doesn't have anything to do with which scripting tools I use.

This is going to be done a *lot* differently than in zMUD. When zMUD was first started, COM didn't even exist! Even after it was added to Windows, it took me several years before I learned what it was all about (which is just as well since it took several years for COM to get stable in Windows). So, by the time I added COM support to zMUD, all I could do was create some COM interfaces as wrappers to existing zMUD Delphi objects.

With the newer versions of Delphi, Delphi objects ARE COM objects. ZuggMail itself will rely on COM to communicate between various core objects. So, you are going to see a *very complete* COM API since ZuggMail itself will be using it. All of the properties of the Delphi objects will be available via COM, for example.

As I've mentioned before in another thread, the initial architecture for the API will be based upon the existing Microsoft Outlook object model. I want to provide as much compatibility as possible with existing Microsoft Outlook plugins and scripts (like my own!)

(oh, this is Zugg, not Chiara...was just fixing some stuff on Chiara's computer and decided to read the forums)

Magician Joined: 13 Oct 2000 Posts: 463

Mmm, sorry. Pet peeve of mine. Honestly, I think going with the free MS stuff is probably the easiest way. But that is because I'm leery of components that have very few users... and anything under 1000 is very few. Even under 10K bothers me. The fewer users you have, the less incentive the company has to fix problems. So unless you have a prior relationship with this company and know they are spot on about fixing bugs and improving their product in a timely manner, I'd go with the MS Scripting tool instead.

At the very least, it means you'll have more company when you bitch on Forums about a bug in the product. :-)

Posted: Thu Apr 01, 2004 10:35 pm

At this point it looks like the answer is either going to be:

(1) by itself,

or

(1) along with (2)

In other words, I'll certainly start with just the MS Scripting engine. As an enhancement later in the development I might add the 3rd party scripting to add syntax checking, etc. But in any case I've decided to allows allow people to use MS Scripting if they want.

(I'm already going to be using other TMS components in other parts of ZuggMail, so it's not going to change the number of companies I'm dealing with)