Zugg Software :: View topic - zApp and eMobius plans for August (and wish list)

Adept Joined: 12 Nov 2000 Posts: 268 Location: Canada

Why? It's not uncommon for IBMers to participate in Open Source projects. Just because IBM itself owns the rights to code we right, doesn't mean they can make a profit it, it is still subject to the licences of the overall application. For instance, there are a lot of IBMers that develop for firefox, as well as many other open source developers. Big Blue is very into linux right now, and a pretty good company overall, not evil (This isn't M$)

Posted: Sun Aug 07, 2005 6:53 pm

Adept Joined: 12 Nov 2000 Posts: 268 Location: Canada

Uhh...I said they werent in the business of creating declarative/scripting languages...they are in the business of creating e-mail clients (I have friends on the Lotus team, I have input into how some features work :p) thats why I said:

Posted: Sun Aug 07, 2005 9:47 pm

Well, Lotus Notes is a lot more than an email client. We did a *lot* of business application development in Notes back at the Lab, but that's probably even more off topic ;)

The market for zMUD is selling a new product to *existing* customers. There are about 60,000 registered users of zMUD, and only a small fraction of those need to buy a new client to keep Zuggsoft alive for another few years. So the MUD market doesn't need to grow for this to work. I just need to deliver something good enough for existing users, and that's where I got excited about all of the new things that are possible in a zApp version vs the legacy code that the current zMUD must deal with. With the plans I have for the new client and the results of the zMUDXP survey over in the zMUD forum, I'm convinced now that this is the correct business decision right now.

Definitely keep an eye on things. I think zApp has an interesting future ahead of it. You might want to make a new thread in the zMUD Developer's forum about the log viewer and what it needs to do. If it's a desktop app rather than a web app then it shouldn't be too hard if you are already used to Java.

Adept Joined: 12 Nov 2000 Posts: 268 Location: Canada

You keep confusing the names of your products :p zApp Developers Forum is what you meant ;)

Posted: Mon Aug 08, 2005 3:40 pm

Bah, yep

... 10-years of habit are hard to break.

Posted: Fri Aug 26, 2005 3:10 pm

I've downloaded and tried zApp Pro and I'm really impressed with the general idea. It's much quicker than getting a .NET app up and running.

I can't wait to see the thing in a more polished form, but frankly before I could use it in any of the companies I consult for it would have to have a polished IDE and much better documentation, it's good to see that you yourself recognise this. I just wish it was all ready now!

One big concern is just how fast it will be on larger programmes, only the new zMud will prove that I suppose. However, in my line of work where I need to throw out a couple of simple dB apps I can see how zApp could really be the solution I'm looking for.

One thing I'm keen to see is how well it handles modularisation, all the demos are single file I get a feeling that it's probably possible to use multiple files, and hopefully the IDE will be designed to reflect that. Many of my apps have very common forms, etc. defining forms in seperate files allows me to quickly build new projects.

As I said, the IDE is really going to be the thing to make or break zApp and it's there you should really focus. I think, ironically, your weak point might be the use of active scripting, especially if it means that you won't be able to include features like syntax checking and intellisense, or even debugging. However I remember from my compsci days when we used to us lex and yacc that all languages' syntax can be readily defined, so it should be possible to write a generic syntax check that checks the language against a lexicon. In fact I'm pretty sure you can probably do this using XSLT. Such a flexible approach would allow developers to add lexicons for other active script compatible languages as the product matures. It would also be great to have integrated language specific help, again if this is done in a generic way then additional help files can be submited by end users. This would mean you could develop the syntaxs and help for perhaps JScript and VBScript, publish the standards and let the community do the rest.

Just some thoughts, no doubt you're thinking along similar lines anyway, hope it helps.

Posted: Fri Aug 26, 2005 3:45 pm

Yep, the new MUD client will be a huge test-case for zApp, just like eMobius was going to be. The new MUD client will be a combination of zApp, along with a set of DLL files. All of the high-performance stuff, such as triggers, MXP processing, etc, will all be done in the DLL. The text scrolling component that needs to be really fast will also be implemented in a DLL (as an ActiveX object). zApp will handle all of the user interface stuff, which doesn't require the speed.

So, developing a large application like zMUD *does* still require some traditional programming tools (Delphi, Visual Studio, etc) to create the high-performance DLL and ActiveX stuff. But zApp is still a great way to handle the customizeable user interface.

I also agree that the modularization is a big issue. zMUD will require many different zApp files, and while zApp handles multiple plugins nicely, it's not so good at handling a "project" concept with multiple source files. This is something that will get improved as I work on the new MUD client.

As far as the IDE, it will probably just offer syntax highlighting to start with. It's relatively easy to have highlighting without true syntax checking. I used lex/yacc in zMUD to implement the syntax checker and debugger there, and it was actually a bit of a pain. A lot of that pain was because the zMUD scripting language didn't lend itself to a formal definition, so it might be easier for better defined languages such as VBscript or JavaScript, but we'll have to wait and see. There's a lot of other work that needs to be done on the IDE first (visual form design, for example).

Posted: Fri Aug 26, 2005 4:06 pm

Thanks for the insights, in one way it's disappointing to see that zMud will still need large sections of it's code implemented as compiled code, though it's not at all unsuprising. On the major plus side it will demonstrate the flexibility of zApp to work as RAD for UIs that can then be easily hooked to compiled code - this will be a major selling point to UI developers and graphic artists, assuming that zApp proves flexible enough, though with the themes support already present, that seems highly likely. I'd be surprised if someone hasn't already written the language definitions for JScript and VBScript for lex/yacc.

My biggest concern is that it seems like a huge amount of work for a single developer to get the IDE to a professional state and I'm worried about how long it'll take you. That said you seem to have been very quick in the past.

Posted: Fri Aug 26, 2005 11:34 pm

Well, it *will* take a while. I'm expecting the new MUD client to take about 2 months. zApp will undergo improvements during that time, but the focus will be on the new MUD client. The zApp IDE will come after that. And I'd say there is probably at least a month of hard work to get the IDE into decent shape.

Multiple all estimates by 2, and you can get an idea of what kind of timescale I might be looking at. Then again, zApp is only one-year old (as of June), so it has already come a *long* way in just a year.

Posted: Sat Sep 03, 2005 12:52 pm

Just to add.. the demo stuff I was working on uses multiple files in the one project quite easily, so it shouldnt be that much of a problem to make it work nicely. I needed to actually have the entity somewhere to include the file, it would be nice to have just a <include type tag that imports items from another file and puts them in the correct places. (Or maybe have head-include files and main-body include files.. )

Lady C.

Newbie Joined: 16 Oct 2005 Posts: 2 Location: France

My thinking about new things to add to zApp:
a) FTP functions
b) When i drag an zml file on zApp.exe the zml code runs.
if i do it again with another zml file that runs ok.
If i have a look to the taskmanager, i can see that zApp.exe is running 2 times in memory, one for each zml app running ?
Could it be possible to only have it only one time in memory whatever the number of zml app running together ?

That's all for me now.

Thank's for zApp.

Dominique

Posted: Sun Oct 30, 2005 10:29 pm

Actually, with the new copy protection system, there is *always* two "zApp" processes. There is a large process and a small one. The small one is part of the copy protection. Sort of like the old RUNSERVICE.EXE that was always running as part of eLicense except that now the second process only runs at the same time zApp is actually running. So I think that might be what you were seeing.

As far as optimizing zApp so that only one copy is running, that is extremely difficult and might also be a licensing issue. zApp uses many 3rd party components that amount to more than $1000 if purchased. To allow only a single memory image of zApp to share those controls, I'd have to put them into a DLL that could be shared, and that would violate the license agreement for most of these 3rd party components (like the DevExpress stuff) since then *any* application could call the same DLL used by zApp to use them.

Keep in mind what zApp is for...it is not for small, fast, memory efficient applications. It is for quick and easy scripting applications or areas where you want to have large customizeability and plugins. It's *always* going to require more memory for a zApp program compared to a compiled app. If you have a task that requires a small memory footprint or fast execution, then zApp is not the proper tool.

Newbie Joined: 16 Oct 2005 Posts: 2 Location: France

ok, i see what you means.
And for ftp functions ?

Posted: Sun Oct 30, 2005 10:51 pm

FTP functions (and other network functions such as sockets) are on the list for zApp. Just can't say when they will be added yet.

Adept Joined: 12 Nov 2000 Posts: 268 Location: Canada

*poke*

Posted: Tue Nov 22, 2005 2:32 am

Poke all you want...nothing's going to happen soon. The zMUDXP stuff is taking a *LOT* longer than I expected. My current detailed schedule shows about 370 hours of work left on it (with about 100 hours completed so far), just to get a basic beta version that I can release. I just don't have time to work on zApp releases right now I'm afraid, sorry.

That's the problem with one-man companies...I can only work on one project at a time.

The only thing I've worked on that effects zApp is to fix various problems with the zMemo control (mostly syntax highlighting stuff). But at the same time, I've upgraded the Spellchecking component and the DevExpress controls, and potentially broken some of the Theme stuff that I haven't had time to work on. Right now all my time is being spent on various low-level database issues getting the zMUD settings into a good SQL database format and dealing with the editor for this settings database. This doesn't have any effect on zApp.

Also, keep in mind that when I mentioned "2 months" back in my post on August 26th, that was before I knew that just getting the new shopping store was going to take more than a month. I only started getting "serious" coding time for zMUDXP towards the end of October.

So, sorry, but I'm going to have to ask for a *lot* of patience from zApp users.

Posted: Tue Nov 22, 2005 2:39 am

Oh, and I think this was mentioned in another thread or in the blog somewhere, but I'll repeat it here in case people are confused. I'm not able to write zMUDXP directly in zApp. I just couldn't get the speed that I needed. Yes, this is sad news for zApp. What I'm doing instead with zMUDXP is essentially bringing zApp code directly into zMUDXP. So, for example, zMUDXP uses the zMemo control for script editing. But it's using that control directly...it's not loading a ZML file or anything like that.

I plan to add features to zMUDXP to load ZML files for things like plugin screens, but the main zMUD interface will not be done in a ZML file...it will be done using Delphi just like in zMUD. Because I'm still using Delphi for zMUDXP, I haven't needed to spend anytime writing the zApp IDE...that has gotten a lower priority. But I had to make this decision to get zMUDXP out as soon as I could.

It was only when I started doing detailed scheduling and planning for zMUDXP that I realized all of this. If I had to implement zMUDXP purely using zApp and also write the zApp IDE, then it was going to take something like 6-8 months to write zMUDXP once I got all of the details listed. I had to go through and eliminate as much as I could to get the project down to something I could release in a more reasonable timeframe. Then I'll improve it over time like I've always done in the past.

But it became really clear that I needed to stick with Delphi and reuse as much existing zMUD code as possible. It just wasn't feasible to convert all of zMUD (900,000 lines of code) into ZML VBScript scripting code. And even my attempts to put the Delphi code into DLLs and call it from zApp didn't work well. I've learned that DLLs are a *real* pain, and cause all sorts of problems. Data sharing is a pain, thread synchonization is a total nightmare. I needed to make things as simple as I could, and that meant doing zMUDXP in Delphi and using zApp technology where appropriate.