Register to post in forums, or Log in to your existing account
 

This forum is locked: you cannot post, reply to, or edit topics.  This topic is locked: you cannot edit posts or make replies.     Home » Forums » General zApp Discussion Goto page Previous  1, 2
Zugg Posted: Fri Jul 22, 2005 5:28 pm
zApp and eMobius plans for August (and wish list)
theNerd
Adept


Joined: 01 Mar 2005
Posts: 277

PostPosted: Sat Aug 06, 2005 9:26 pm   
 
theNerd wrote:
However, just think how interesting it would be if IBM owned some zApp code... hmmmm....


I was thinking about ZML code here, not actual Delphi code written by Zugg. I just thought that would be an interesting concept for a big company like IBM owning ZML code.
Reply with quote
Krule
Adept


Joined: 12 Nov 2000
Posts: 268
Location: Canada

PostPosted: Sat Aug 06, 2005 10:32 pm   
 
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$)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Sun Aug 07, 2005 6:53 pm   
 
Quote:
Secondly, IBM isn't in the business of creating declarative/scripting languages

That's not really true. IBM bought Lotus Notes many years ago. I've used Lotus Notes extensively and you can customize it so much that you could pretty easily put together an email client like eMobius (customizing the existing Notes Mail application). The problem with Notes is that it's expensive and requires a server infrastructure than individuals and small businesses just can't handle. But zApp and Lotus Notes are similar in *many* ways.

Anyway, yes, the issue with you working at IBM is very common. Almost every large tech company has similar "contracts" with it's workers. It's one of the prices you have to pay for work for a big company like that. They want you to put your intellectual effort into your job and helping the company and not doing your own personal projects on the side.

As far as eMobius, I wanted to add that I still really *need* an email client like eMobius too. So we are in the same boat. I also don't MUD anymore (although I might have to start playing again to make the new MUD client successful). Working on zMUD anymore was essentially impossible from a business perspective with the free upgrade policy in place. It was only after talking with someone about how much I was hurting both myself and my customers by stubornly sticking with that policy that I started thinking "outside the box". Once I started making a list of all of the things I could improve in zMUD if I was using zApp in a fresh new version, I got more excited about the possibility, and realized that the income from a new MUD client could save the future of Zugg Software even quicker than a new email client.

Someone also pointed out that I currently had the leading software product in a niche market (zMUD), and very good brand name recognition. They mentioned that it seemed a bit silly to give up that position to enter a hugely competitive market (email) where my brand name would be meaningless. Certainly makes a lot of sense to stick with my proven strength when you think about it that way.

But Krule, don't worry...I need a new email client too. Maybe Thunderbird will continue to improve to the point where it becomes the best choice. But it's also possible that doing the new MUD client will improve zApp to the point that eMobius is even easier, and in the long run it might not actually delay eMobius as much as we think.
Reply with quote
Krule
Adept


Joined: 12 Nov 2000
Posts: 268
Location: Canada

PostPosted: Sun Aug 07, 2005 6:59 pm   
 
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:

Quote:

...as far as eMobius is concerned, I suppose that I'd have to refrain from doing so.


But yeah.,..I do believe there is a market for zApp, I'm not entirely convinced about a market for zMud unless there are a lot more mudders out there that I don't know about..which is possible. Do your thing, in the meantime, I'll deal with Outlooks annoyances (had another one the other deal, couldn't delete a folder because it had too many emails in it..thats a nice trick). I am still going to watch the progress of zApp itself, as I'm interested in it.

And if anyone is up to the challenge of making a log viewer in zApp, I'm almost finished my Java version (Working on a search dialog right now, then the filtering, and I'm done)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Krule
Adept


Joined: 12 Nov 2000
Posts: 268
Location: Canada

PostPosted: Sun Aug 07, 2005 9:53 pm   
 
You keep confusing the names of your products :p zApp Developers Forum is what you meant ;)
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: Mon Aug 08, 2005 3:40 pm   
 
Bah, yep Embarassed ... 10-years of habit are hard to break.
Reply with quote
thargy
Beginner


Joined: 10 Aug 2004
Posts: 20
Location: UK, Uganda

PostPosted: 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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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).
Reply with quote
thargy
Beginner


Joined: 10 Aug 2004
Posts: 20
Location: UK, Uganda

PostPosted: 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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Castaway
GURU


Joined: 10 Oct 2000
Posts: 793
Location: Swindon, England

PostPosted: 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.
Reply with quote
DominiqueB
Newbie


Joined: 16 Oct 2005
Posts: 2
Location: France

PostPosted: Sat Oct 29, 2005 10:42 pm   Hello and suggestions from a new user . . .
 
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
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
DominiqueB
Newbie


Joined: 16 Oct 2005
Posts: 2
Location: France

PostPosted: Sun Oct 30, 2005 10:45 pm   
 
ok, i see what you means.
And for ftp functions ?
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Krule
Adept


Joined: 12 Nov 2000
Posts: 268
Location: Canada

PostPosted: Tue Nov 22, 2005 2:12 am   
 
*poke*
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Zugg
MASTER


Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA

PostPosted: 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.
Reply with quote
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.     Home » Forums » General zApp Discussion All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
© 2009 Zugg Software. Hosted on Wolfpaw.net