> Yes I have but AJAX is not the only way to do things.

Right now it's the only way to avoid to reload an entire page every time you click somewhere. And it is done in JavaScript. And even if you don't use AJAX if you want a modern looking web page you will end up writing a lot of JavaScript. HTML itself is no longer enough.

> if there is no need for anything more than the stdin/stdout redirection then anything more is a moot point. 

Never said that CGI can't work - just that it's being phased out due to its shortcomings. You can code the application of tomorrow, or that of yesterday.

> Ok, I see you want to be picky.

No, I am just correct. That's science - you can be correct or wrong, not "picky". Therefore I have no misconception about what is needed and what is not.

> Now to address the subject of dll files. As of Windows 2000,  dll files once loaded stay in memory until the system is rebooted,

Again, not true.

> HKEY_LOCAL_MACHINE > Software > Microsoft > Windows > CurrentVersion > Explorer > AlwaysUnloadDLL

That's just avoid the "cache time" Windows Explorer uses when an application exits and its dll are unloaded - as long no other application uses them. That's to avoid to reload them from disk if the next app needs them. Ask yourself why this key is not the default if so useful...

>. You cannot tax 486 DX2 66 on a T1 with NT4 running, with todays computers....

Don't know where you live, but I can easily overwhelm a P4 with Windows 2003 with the bandwith and users available here.

> So you are implying that I cannot write a webmail system that is useful and should use an existing package. 

No, I am just implying that your foundations are probably wrong, or obsolete. Feel free to write your own, but I suggest you to compare yours with those already available, and ask yourself why someone should use yours instead of the others.

> Because I want to. 

Good luck. Bidirectional synchronization is always a nightmare, believe me. You are just reimplmenting the wheel, adding more complexity and the need of more resources, with no benefits. But you're the kind of guy who needs to hit the wall to acknowledge it's there.

Then feel free to insult me when you're unable to support you claims with facts.

I have been toying with the idea of writing a webmail for Mercury. There is no point in writing something using IMAP, Squirrel Mail does a very good job there. This leaves 2 possible (as far as I can see) alternatives.

1) Have the webmail act as a traditional mail client where the mail is retrieved from Mercury just like Pegasus would do. The webserver would create a folder for each user as and when necessary.

2) Have the webmail go directly to the user folder in Mercury and work with the mail files directly.

Item one would allow the websever to be on a separate server (or the same as Mercury).

Item two would have to be closely integrated with Mercury. There would have to be some kind of locking mechanism to prevent a simultaneous webmail session and POP3/IMAP session or the s**t will hit the fan.  Sending mail could bypass the SMTP and be injected into the queue. Most people want to be able to create folders, this in its self is not a problem but if the user wants to use a mail client, these folders will not show up unless the user is using IMAP.

One of the problems I have encountered in the past is Webmail users that just do not cleanup their mail boxes. Mercury does not have "quota" so there is no means of enforcing this. Item one, being separate from Mercury could enforce quota and it is conceivable to allow the admin to set quota on an individual user basis.

Item one would be a generic webmail server and I am sure that there is more than one free package out there.

Item two would truly be Mercury Webmail.

Your thoughts. 

As a technician I'm often too wrong on time assumptions for my little projects. Don't want to be too pessimistic here, but building a native Mercury WebMail client is a very large task, since the competition is already established, large, with all sorts of variances. I don't think it is realistic without a team of 4-6 really good web-programmers to even get something descent to release publicly.

But nevertheless, if you manage to compile a WebMail message client, with a proper adressbook, calendar and notes abilities that can work on and synchronize with most PDAs - you will have a market.

My first bias is to simply allow IMAP to be used for MOST webmail functionality. However, building a custom webmail client, you COULD build some customization based on mercury. I do think you need to support it running on an external server as a standard.

I would expect the customization functions to be available as a web service.

But beyond administration, do we need anything beyond IMAP for functionality?

I do not see a problem with web page development as long as one does not try and impress one self with ones own brilliance. The web pages need to be functional and laid out in an easy to understand manner. As with all webpages, navigation must be straight forward and consistent, with nothing more than 3 clicks away.

I do not consider writing html to be programming.  The CGI on the other hand is. CGI is not the easiest thing to debug because the CGI is run by the web server and getting feedback as to what is going wrong is problematic.  I have always used "cgic" as a library for writing CGI stuff and it is a great time saver. This means that the CGI is written in C. To my mind having the CGI in an executable beats any interpreted language hands down. The interpreter has to turn the programming code into machine code at run time, why do that when you can have a machine code program.

Address book.  There is a java script or two that will handle that problem, I downloaded one last night.

Calender and note are much the same, something like sql light would fit that bill. There are a couple of other light weight DB library's that would be useful without the bother of constructing sql statements (that then have to be interpreted).

PDAs, I don not have one and don't want one but I can learn or maybe someone else would like to take that on.

I think a team of C programmers who could take on a section of the CGI work would be good. Two-three, any more and consensus becomes to hard to reach.

My experience with webmail is that most of the people who habitually use it (road warriors excepted) do so because they cannot get a regular email client to work or cannot work with an (any) email client. Rarely, the problem is with the computer, the rest is a user problem. Mostly they can't be bothered to learn, it is too difficult but the have mastered opening a web browser. These people do not need options, it confuses them and gives them the opportunity to mess them selves up. The remaining people are casual users who want to check their email when on holiday etc. and are just happy that they can.

IMAP is one way to do it but when the user uses both webmail and a pop3 client (most users don't have a clue what IMAP is or does), there is a problem. My experience has been that when a user cannot make something work or does not understand it, the ISP is doing something to them. So folders in webmail and not with POP3 is a problem.

In some ways having the webmail retrieve messages via POP3 with the default option, to leave mail on sever, is the least problematic. You just have pre defined "inbox", "out box" and "trash", with no option to make folders (an admin option to enable folder creation for specific users would be good).  You make sure the user understands that they can use both POP3 and webmail the same way.  The biggest problem with IMAP (and webmail) is users who do not delete their old messages and then complain about it getting slower and slower. Squirrel mail (or is it IMAP) is really bad for that and also for orphaning session files, they are just abandoned. "Emurl", suffers from the same problem and being in ASP it is sort of castrated from the get go.

Web admin, do you mean of the webmail, if so, of course. If you mean Mercury, I am the wrong guy to talk to although it would be possible to change the "murcury.ini" file and others as necessary via a web interface. it would be necessary to stop and start Mercury in order for the changes to take place. It is easy to stop and start an NT service, I have never tried to stop/start an application as Mercury runs. I am sure an example can be found on the web. Programatically stopping an app is what I do not know how to do, starting is easy.

Running on an external/same server could be done easily. Mapping a shared folder is a quick and dirty way. Writing a server to handle chores on the Mercury machine is perhaps the more elegant way, the data could even be encrypted. Could even be encrypted with a one time, throw away encryption but that is getting paranoid. Email is like a postcard, any one can read it.

There are good points and bad from any method of implementing webmail but most of the problems emanate from the user (about 20% are just, shall we say, fall into the customer code of  "1D10T") and that is what has to be addressed as best as possible.

[quote user="retyred-isp"] Address book.  There is a java script or two that will handle that problem, I downloaded one last night.

Calender and note are much the same, something like sql light would fit that bill. There are a couple of other light weight DB library's that would be useful without the bother of constructing sql statements (that then have to be interpreted).[/quote]

I saw someones signature on IT-Professionals community - that says it all:

"If it was easy - anyone could hack it."

>I do not see a problem with web page development as long as one does not try and impress one self with ones own brilliance.

Users are getting more and more used to sophisticated web application. Deliver them one that is not and they will perceive it as "out-of-date" or "cheap" application.

> I do not consider writing html to be programming.  The CGI on the other hand is. CGI is not the easiest thing to debug because

HTML is not programming, it's page design and have it's own difficulties, crafting a nice page requires the proper skills. But JavaScript *is* programming, and it is usually tightly coupled with the page design. CGI are the "old way" to do web applications, because they are slow and don't scale well, especially under Windows where creating a new process is an expensive task, much more expensive than under Windows - and no way to cache connections or the like easily. One would need a web server to run a CGI - and once he has it he could use it to run any of the excellent web mail clients already available.

Web mail client uses IMAP because with a webmail one has no choice but to store mails on the server, using POP3 would give a very poor web application - no way to organize mails at all.

> Users are getting more and more used to sophisticated web application. Deliver them one that is not and they will perceive it as "out-of-date" or "cheap" > application.

I do not know how you mean the term  "sophisticated" to be taken. Some people think sophisticated is cute animations and page transitions, I call this useless.  I believe in KISS. Do the job necessary with a minimum of fuss.

> HTML is not programming, it's page design and have it's own difficulties, crafting a nice page requires the proper skills. 

It really requires a knowledge of HTML tags and how and when to use them. What tags are browser specific. Being able to write html in notepad is a definite asset as this requires one to know and understand HTML. Consistent navigation and page layout. We are not making a glossy magazine with webmail but a workhorse that need to be easy to use and understand. 

> But JavaScript *is* programming, and it is usually tightly coupled with the page design.

JavaScripting for web pages is usually minimal/trivial to do things at the client side prior to submitting a form (in the  case of web mail) so the form is correct before being sent to the server.  It is also useful for moving data between different forms and web pages forms that makes the CGI side of things easier to program and also more convenient for the user.  One could use the "Swing" interface and have a web page that looks and acts like a regular GUI application. The down side of "Swing" is that it takes long time to download so I will not go there.

> CGI are the "old way" to do web applications,

CGI is the ONLY way to do web applications. It matters not if PHP, pearl, java, asp or a plain old exe is on the server back end. CGI is the method of getting data from the client web browser to the web server and cannot be avoided.

> because they are slow and don't scale well, especially under Windows where creating a new process is an expensive task

You have to do it, like it or not. The only way to possibly alleviate the situation is to use ISSAPI (use a dll rather than an exe) with MS IIS where multiple instances of the same dll can run at the same time. Where a server is heavily taxed this can be to the good. It is good to remember 2 things:

- 1) The dll lives in memory only while it is actively being used and is unloaded when the last instance is unloaded.

- 2) Dynamically linking has a higher overhead than loading an exe.

We have to make a choice based on how heavily the server will be used and the likely hood of multiple instances of the same code (exe or dll) being used at the same time. However this is all rather irrelevant because the real limiting factor is bandwith, the lack of enough to tax the server. The load overhead and all the LINUX v MS squabbles becomes a mute point.

> and no way to cache connections or the like easily. 

Err.  This is a client server relationship. Once the transaction is completed the connection is closed.  Keeping a connection  open just wastes sockets and the associated 2k of memory on both the client and the server. It is generally a bad idea, especially if the socket is kept open with no activity and then times out, a bit of a nightmare. Keep alives that just stop the timeout are really only useful when the client side computer is slow, very slow.

> one would need a web server to run a CGI

Earlier you said that CGI was the old way of doing it and now you are extolling its virtues. Just what is your position on CGI? I have never met a webserver that did not do CGI and if it did not do CGI I would not bother with it. I do not think that it is possible to have webmail without a web server, is there something new out?

 >  - and once he has it he could use it to run any of the excellent web mail clients already available.

 I have never seen a webmail client, must be new. I have seen web pages served up by web servers that gives webmail.

Has the thought struck you that I might like doing web pages, messing with Java and programming. That it may just be an exercise on my part for pure enjoyment. Lots of people do this, thats where all the freeware comes from.

> Web mail client uses IMAP because with a webmail one has no choice but to store mails on the server, using POP3 would give a very poor web
> application - no way to organize mails at all.

Wrong.  Web mail can use IMAP but is not limited to IMAP. IMAP stores the mail on the mail server and the user can organize mail into various folders.  Having webmail get new mail via the POP3 interface just means that the mail is stored by the webserver. It does not mean that there cannot be folders that the user can organize their mail in. It does not mean that the user cannot create their own folders.  Anything doable via IMAP is doable via any webserver that is storing the mail. Other things can be achieved like getting mail from multiple POP3 servers.  The last time I looked Squirrel mail did not do that.

I think that you are laboring under some misconceptions of what can or cannot be done via the Common Gateway Interface. What can be done is limited only by ones ability to write the software to do whatever one wants as long as the operating system able. Anything you want, be it wise or not.  I like to use exe files for CGI because the only constraints are ones knowledge and good sense. CGI programs are usually quite trivial in nature, just a bother to debug but being trivial mostly do not need debugging.

.

> I do not know how you mean the term  "sophisticated" to be taken. Some people think sophisticated is cute animations and page transitions

Never heard the word "AJAX", right?

> We are not making a glossy magazine with webmail but a workhorse that need to be easy to use and understand.  

Right. One needs to know how to design a web GUI and that's require skill too.

 > JavaScripting for web pages is usually minimal to do things at the client side prior to submitting a form

Where do you live? Pluto? Never gave a look to GMail, for example? Or the new Yahoo mail? Try, you would discover a whole new JavaScript world.

> CGI is the ONLY way to do web applications.

No. It's just an technique of the old days using stdin/stdout to communicate with the web server. It has many limits. That's why IIS introduced ISAPI and Apache its "modules". They "talk" directly to the web server in ways CGI with its stdin/stdout interface simply can't.

> CGI is the method of getting data from the client web browser to the web server and cannot be avoided.

Sorry, that method is called "HTTP", not CGI. CGI is just a technique to allow a web server to call an external process and ask it to create the content of an HTTP response.

> 1) The dll lives in memory only while it is actively being used and is unloaded when the last instance is finished.

Better you look at your Windows programming book again.

> 2) Dynamically linking has a higher overhead than loading an exe.

LOL!!! Try to profile it - and remember you need to load a DLL once, while you need to create a process every time. Moreover a DLL lives in the process space of the calling application, while an exe lives in completely separated process space - and that's mean expensive interprocess communication to share data. Ask yourself why any Windows application relies so heavily on dlls instead of exes...

> multiple instances of the same code (exe or dll)

DLLs exists in first place to avoid to load in memory multiple instance of the same code...

> Err.  This is a client server relationship. Once the transaction is completed the connection is closed.  Keeping a connection  open just wastes sockets

Try not to cache connections, and re-establish it and thereby reauthenticate the user every time a command to the mail server needs to be issued. Good luck!

> Earlier you said that CGI was the old way of doing it and now you are extolling its virtues

No virtues at all. Unless you integrate the web mail capability within Mercury itself but rely on any web server technology - be it CGI, ISAPI, ASP, ASP.NET or an Apache module you'd need a web server. And once you have it why should you rely on some limited cgi web client when there are many applications available that will deliver sophisticated web clients?

> Wrong.  IMAP stores the mail on the mail server and the

Exactly what I wrote.

> Having webmail get new mail via the POP3 interface just means that the mail is stored by the webserver.
>It does not mean that there cannot be folders that the user can organize their mail in.
 >It does not mean that the user cannot create their own folders.
>Anything doable via IMAP is doable via any webserver that is storing the mail.  

LOL!!! Why anybody should reimplement from scratch something that already exists and works in the IMAP server???? And with all the hassle to keep the two in synch??

> I think that you are laboring under some misconceptions of

I think you have many misconception about actual web development - and many other programming topics.

> Never heard the word "AJAX", right?

Oh but I have, My wife uses it in the bathroom.  

Yes I have but AJAX is not the only way to do things. Ajax is just another tool that may be employed but not the only tool at ones disposal.

 > Right. One needs to know how to design a web GUI and that's require skill too.

To a point. Everything is hard when you do not know how and gets easier as one learns more. I would not consider myself a graphic artist but I do know when something looks good and is easy for a user, that is the main aim, is it not. I may have to work at it a little harder than the truly talented.  

> No. It's just an technique of the old days using stdin/stdout to

communicate with the web server. It has many limits. That's why

IIS introduced ISAP
> and Apache its "modules". They "talk" directly to

the web server in ways CGI with its stdin/stdout interface simply can't.

If there is no need for anything more than the stdin/stdout redirection then anything more is a moot point.

> Sorry, that method is called "HTTP", not CGI. CGI is just a technique

to allow a web server to call an external process and ask it to create

the content
>of an HTTP response.

Ok, I see you want to be picky. I really do not care how the form submission gets to the web server, only that it does in a timely fashion. I care that the form submission is passed by the server in MIME format, anything else is irrelevant and out of my control anyway.

Now to address the subject of dll files. As of Windows 2000,  dll files once loaded stay in memory until the system is rebooted, in the default as installed configuration (using up memory and swap file) on a system with less than !gig it is advisable to disable this "feature", see:

HKEY_LOCAL_MACHINE > Software > Microsoft > Windows > CurrentVersion > Explorer > AlwaysUnloadDLL

This prevents hard drive thrashing by freeing up memory. One cannot assume that the dll once loaded will remain in memory at all times. Prior to Win 2K the dll was always unloaded after the last instance finished, Win 2k and later it is optional.

I did mention that a web server needs to be heavily taxed the get any real benefit of multiple instances and to get a server heavily taxed you need major bandwidth. You cannot tax 486 DX2 66 on a T1 with NT4 running, with todays computers.... Getting multiple instances of a DLL or EXE are slim and the user will not will not be able to detect a dll or exe being loaded because the slow part is the network and all the computing power in the world is not going to make TCP/IP faster.

> Try not to cache connections, and re-establish it and thereby

reauthenticate the user every time a command to the mail server needs

to be issued.
> Good luck!

Ah now you make yourself clear.  Caching a connection is only necessary if you issue the  TOP command so that mail can be selectively downloaded or deleted. Most mail clients just download all mail in the mail box. As for implementing a cache of socket connections should one want to use the TOP command, is not that hard. A service would do nicely, I do not see a problem as long as idle connections timeout and the connection is closed.

>No virtues at all. Unless you integrate the web mail capability within

Mercury itself

As you should know, I cannot integrate webmail into Mercury, I do not have access to the source code.

> but rely on any web server technology - be it CGI,

ISAPI, ASP, ASP.NET or an Apache module you'd need a web server. And

once you have it why
> should you rely on some limited cgi web client

when there are many applications available that will deliver

sophisticated web clients?

So you are implying that I cannot write a webmail system that is useful and should use an existing package. 

> LOL!!! Why anybody should reimplement from scratch something that

already exists and works in the IMAP server???? And with all the hassle
> to keep the two in synch??

Because I want to. 

> I think you have many misconception about actual web development - and many other programming topics.

I probably do but I seem to get things done one way or another, it is surprising what a guy can do if he are determined and wants to learn.

I have met you before, in the news groups. Where people who write as you do are known as trolls. Were this no a place for serious discussion I would have fun with you by throwing out troll bait. Please do not respond to this, I am not intimidated by your cyber bullying and have far more interesting things to do than play your game.