Question: Are you looking to create an IMAP server? Or just interact with an IMAP server?
The reason I am asking is this. The New @EMAIL and @EMAILSESSION tags let you interact with an IMAP/POP3 server, but they don't let you create an IMAP Server. Just wanted to clarify this. Ben Johansen - http://www.pcforge.com Authorized Witango Reseller http://www.pcforge.com/WitangoGoodies.htm Latest downloads & List Archives @ http://www.witango.ws -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Garth Penglase Sent: Thursday, August 01, 2002 7:15 PM To: Multiple recipients of list witango-talk Subject: Witango-Talk: Webmail solution - any interest? Sure. I want to do it, but how to do it? commercially or communally? I've been tossing the idea of doing my own IMAP webmail interface around in my head for a while now. All I have read about what has been done already with custom headers and email systems makes me believe that I can do something like this, particularly with the new product and its more advanced email handling (from the little that I know from reading Scott Cadillac's run-down and a couple of other emails). My only concern is that, while it would be as good as a standard perl / cgi based system which calls cgi or pl routines from disk, similar to current Tango, what I want to build is something more along the lines of a java based product similar to Sake ( http://www.endymion.com ) which, when run on Jserv or Tomcat (mac os x server comes with tomcat I believe), loads the application files once into RAM and then spawns a session for each new user. This product has the benefit of being significantly faster and more scalable, and when using IMAP, is truly portable. I have set up a webmail system on Linux (ie NetWin's dmailweb) which worked well and is a simple way to go, but required direct use and access to the Linux user system. This means that you can't really expect to install a system like that on someone else's web server - maybe you could with my envisaged product. Also it means that if you want to move to another webmail system in the future, if you aren't using IMAP (which I wasn't with dmailweb, though I think it is an option) you are stuck with a porting problem in regards to the existing email. And besides, the user authentication system is all setup using Linux users. So I want something which is truly portable, scalable, IMAP based for email portability, and easy to configure. The only way I can see to do this is to create it in tango (oops... sorry Richard, it'll be Witango then, won't it) and deploy to java, hopefully giving me the best of both worlds: new funky email tags in Witango and scalability in java. And with an easy setup process and admin system second to none hopefully. I might just have a good product which could be useful to more people than just me. And it has to have pretty much all of the main features that Yahoo et al have (though the virus scanning of emails might be a doozy of an issue). Am I having myself on, or is this possible? I think it is, and when I have something like a schema worked out, I'd be happy to share it. Maybe I should look at doing it as a cheaply priced commercially available product similar to what Robert's doing with the image thing. Maybe we should do it communally and all own the rights to it if it is bigger than Ben Hur and then use it as an example of what we can do as a community. Garth At 07:19 2/08/02 -0500, you wrote: >Garth > > > >I have been wanting to do what you mentioned. When you have a skeleton >type of logic flow for the IMAP project, I would really like to see your >layout. > >Steve > > >-----Original Message----- >From: Garth Penglase [mailto:[EMAIL PROTECTED]] >Sent: Thursday, August 01, 2002 1:34 PM >To: Multiple recipients of list witango-talk >Subject: Re: Witango-Talk: Comparing WO to Witango > >When Apple dropped the price of WO I was about to debunk, but to be >quite >open about it Robert, it has been some of your posts on this issue that >have galvanised my position on this toward WiTango, even though it >offered >java deployment when WiTango didn't. > >I myself have grown as a programmer through using WiTango and using this > >list, though I could never put myself in the same category as some of >the >members of this list, obviously. Having said that, there has never been >a >project that I haven't been able to complete successfully using Tango, >and >on some of the earlier ones we were pushing the envelope somewhat. > >My next projects will certainly test the ease of development though: >- a full featured IMAP webmail interface for my celtic community site >- a celtic community college where all of the courses are conducted >securely online. >- and maybe a XML web site accessing Novell's Directory services pulling > >together 8 disparate databases. > >Garth > > >At 10:28 1/08/02 -0700, you wrote: > >It is more than just getting used to something. I literally spent over >30 > >days like a monk with WO. It is just not possible to develop as quickly > >IMHO. Or I would have gutted it out. I will look for them, but there >have > >been several articles written about this, that WO is a burden on small >to > >medium size apps, and 90% of development falls into this category. If >you > >are going to write the ecommerce site for dell, use WO. Its rigid > >object/class structure lends itself to a huge project with multiple > >developers. But I dare say that tango has the ability to do this also, >you > >just also have the ability to "cheat" and get it done quickly. > > > >A good example is the TCF. A TCF should be an object, like a class file >in > >java, a separate piece of code with an input/output inteface. It should > >adhere to this strict structure so that it can only manipulate what it >is > >passed, and then spit out its output. But we all know that we can >access > >many variables from with the TCF and sometimes use it in ways that >makes it > >not an "object" at all. But who cares. I choose to use TCFs as true >objects > >for code portability across applications. If a developer wants to >"cheat", > >let him. That is part of the greatness of Witango, it is as flexible or >as > >rigid as you desire. I have a few apps that I wrote when I was a >newbie, > >that I would be embarrassed to share, but at least I got the job done. >I > >would never have been able to tackle WO at that level. But as I have >grown > >as a developer, I would put my apps up with anyones. They are >structured, > >and logical. Witango helped me get there. > > > >Sorry for the rambling. > > > >-- > > > >Robert Garcia > >BigHead Technology > >2781 N Carlmont Pl > >Simi Valley, CA 93065 > >Phone 805.501.1390 > >Fax 805.522.8557 > >http://www.bighead.net/ > >[EMAIL PROTECTED] > > > > > > > From: Garth Penglase <[EMAIL PROTECTED]> > > > Reply-To: [EMAIL PROTECTED] > > > Date: Fri, 02 Aug 2002 02:42:27 +1000 > > > To: Multiple recipients of list witango-talk ><[EMAIL PROTECTED]> > > > Subject: RE: Witango-Talk: Comparing WO to Witango > > > > > > I think that once you get used to something, unless there are >significant > > > drawbacks (such as lack of cross-platform in Alex's case, (previous) >lack > > > of Java deployment etc.) with your current tools you stick with what >you > > > have invested the most time with. > > > >_______________________________________________________________________ >_ > >TO UNSUBSCRIBE: send a plain text/US ASCII email to >[EMAIL PROTECTED] > > with unsubscribe witango-talk in the message body > >_______________________________________________________________________ _ >TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > with unsubscribe witango-talk in the message body >_______________________________________________________________________ _ >TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > with unsubscribe witango-talk in the message body ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
