Page 3 of 3 FirstFirst 123
Results 41 to 52 of 52
  1. #41  
    Originally posted by nfodor
    And finally, maybe the most important, a certain segment of the population, most of it, do not wish to switch their email address to any new mail provider, including the one you're recommending, they want a solution that works with their existing email without putting a new email address in the middle and then forwarding it to it.
    OK if we're allowed to throw in a middle tier proxy into the equation then what's stopping me from using FastMail IMAP as my proxy to push me my POP3 mail? You can configure it to poll your POP boxes or hey... even faster, you can just simply push (ahhh... I mean "forward" ) your original mail to FastMail. FastMail also supports polling the 250 million user accounts on MSN and HotMail. Ok... go on call me the devils advocate.


    Originally posted by Maniac8888
    To date, there isn't a single Palm IMAP4 e-mail client that is RFC compliant. MultiMail was the closed and that is no longer available. Perhaps Chatter and/or PushMail are beginnings in this area. I certainly hope someone does it.
    To qualify for the right to respond to this thread you need to have written an email client - so when are you releasing? (Kidding).

    Actually, the word "fully RFC compliant" has been thrown around a lot - can someone explain to me what that means? I would say that you have to comply to RFC standards to fetch any kind of mail. Do you mean closest to supporting the full RFC spec'd functionality... the whole kaboodle? Like server side searches, selective downloads on sub-message MIME components, etc etc - i.e. the cool stuff that Outlook doesn't come close to supporting?

    -W
    Will Lau


    www.snappermail.com

    A Killer Email Client for Palm OS Smartphones, now available...
  2. #42  
    Originally posted by mblank
    Why not just admit you're ignorant about IMAP? IMAP servers can push (P - U - S - H) information about new messages without need of a "sync" (whatever that is). The processor doesn't have to be on all of the time to do this.
    Are you talking about the IDLE command?
    http://www.ietf.org/rfc/rfc2177.txt

    I'm still confused about your approach. I sense that you are reluctant to spell out what/how you maintain a continuous TCP connection in your palm application. I'm not trying to steal any trade secrets or anything -- it's just hard to compare it to other approaches without some details.

    Generically I see your approach, from your posts on other threads. You have a TCP socket which remains connected to your server. Your server maintains connections to an IMAP and a Jabber. Information from these sources is pushed to the device via your own protocol.

    I can see several ways to code that, but I'm curious as to which approach you've settled on.

    I've thought about moving my stuff over to concurrent retrieval rather than during idle times as I do now. But I think it'd be a lot of work with hardly any gain. I mean, my mailbox is already 10 minutes stale due to my use of fetchmail on the server.
  3. #43  
    Originally posted by snapperfish
    OK if we're allowed to throw in a middle tier proxy into the equation then what's stopping me from using FastMail IMAP as my proxy to push me my POP3 mail? You can configure it to poll your POP boxes or hey... even faster, you can just simply push (ahhh... I mean "forward" ) your original mail to FastMail. FastMail also supports polling the 250 million user accounts on MSN and HotMail. Ok... go on call me the devils advocate.
    FWIW I have sortof a middle-man approach. I chose PHP as the middleware because lots of web accounts allow users to upload .php files. Then I found out about the excellent integrated POP3 and IMAP functions.

    Just a wee-bitty program can access a POP3 (as shown) or by changing the imap_open parms it can access an IMAP. Of course you should check for errors etc, I am just cut & pasting a simple example for illustrative purposes.

    <?php
    ob_start("ob_gzhandler");
    header("Content-Type: application/octet-stream");
    $mbox = imap_open("{localhost:110/pop3}INBOX", $HTTP_POST_VARS["user"], $HTTP_POST_VARS["pass"]);
    $cnt = imap_num_msg($mbox);
    for ($i=1; $i <= $cnt; $i++) {
    $Hdr = imap_fetchheader($mbox, $i);
    $Bdy = imap_body($mbox, $i);
    Echo "$Hdr" . "$Bdy";
    }
    imap_close($mbox);
    exit;
    ?>

    Anyways, the point is, you throw that page on a php-capable web site, and you have a very easy way to download/filter/middleware, gzip compressed messages from POP3 or IMAP. The gzip compression is compatible with Palm Zlib.

    It's really paying off on quick configurability. Most of the changes have been to simple php scripts rather than having to change client code.
  4. #44  
    potatoho -

    I don't use any sort of proxy for IMAP, and I have no proprietary protocol anywhere in the chain.

    I am connected directly to an IMAP server (which could e any IMAP server). IM's go through a multi-IM (Jabber) server which handles the processing for the various IM services.

    - Marc
  5. #45  
    Originally posted by snapperfish

    FastMail also supports polling the 250 million user accounts on MSN and HotMail.
    We are talking about 250,000 constantly open TCP connections here. We are routinely design
    our software for 2,000,000 and more users. It may work for smaller setup, but does not scale very well for such requirements.

    Vadim
  6. #46  
    Originally posted by mblank
    Wrong, wrong, wrong. And it's becoming exasperating.



    The message will not be smaller, but there's much less work involved in getting it. Among other things, you don't have to check which messages are new. (BTW, IMAP is designed to have the server-side component handle complex tasks rather than having this done by the client. Where have I heard that before?)



    Nope. You can be reading mail, writing new mail, or doing any IM task while mail is being read with Chatter. I wouldn't call that single-tasking.



    Why not just admit you're ignorant about IMAP? IMAP servers can push (P - U - S - H) information about new messages without need of a "sync" (whatever that is). The processor doesn't have to be on all of the time to do this.



    Great! I never said that people shouldn't use POP3, or that they should change their provider (although I don't know of ANY IMAP user who has ever wanted to switch back to POP). MY point is that your technical knowledge is lacking when it comes to a) what is and isn't possible on the Treo and b) IMAP eMail.

    I've said nothing about whether your product is a good one or not; I'm simply responding to your misleading statements.

    - m
    Ok, I will stay polite :-> after all there is enough to fight about out there, and this is only a technical discussion. Interesting one though.

    By syncing I meant permanently exchanging info on both sides of the channel, this involves a permanent connection unless you have a listening socket. (About my knowledge of IMAP, I wrote 2 servers in a previous life, and I suffer enough with it's arcane and non standard client compliance as many others did including Mark Crespin who invented the protocol with Bill Yeager). So IMAP does push yes if pushing is for the client to become a listener (a server). And that is the problem on the Palm, with IMAP or any other protocol because it is not built to do that.

    Now when it comes to single tasking I meant that I am still to see an email client on the Palm that lets you retrieve your mail on the background while you place a call or run another app. Please indicate one if you know it.

    Also to make sure that you understand that my goal is not to asses the merit of IMAP as opposed to other protocols: My point is only that a good product must not change people settings but adapt to it. We have market research showing lots of POP users and Hotmail etc... so we adapt to them. We also have Treo owners out there who need immediate reception of incoming email from their existing accounts and we want them to read them as soon as possible.
    What matters is the customer and his current settings. We are not going to teach him anything, rather learn from him.

    So to summarize: PushMail supports accounts with POP access and Hotmail/MSN, without the need for a user to create a new email account somewhere or to run anything on his PC. It will SPAM filter his email, content transform it so it comes faster and wake up his phone for immediate retrieval, one way or the other depending on the underlying technology, immediately after his message has arrived.
    We offer an email client to do so and we do provide optimized POP access (Without the need to create a new email account) so one can use any POP compliant email client and still benefit from message transformation, filtering and antispam off their original mailbox.

    See ? It's simple :-> Nothing for you to get exasperated about!
  7. #47  
    You've lost me here.

    By syncing I meant permanently exchanging info on both sides of the channel, this involves a permanent connection unless you have a listening socket .... So IMAP does push yes if pushing is for the client to become a listener (a server). And that is the problem on the Palm, with IMAP or any other protocol because it is not built to do that.
    I don't know what you mean by "permanently exchanging info on both sides of the channel". But Chatter doesn't do anything like that. And are you saying that Chatter (the client) is somehow a server? Because nothing could be further from the truth. (BTW, I remember Mark Crispin from when he was an undergrad).

    Now when it comes to single tasking I meant that I am still to see an email client on the Palm that lets you retrieve your mail on the background while you place a call or run another app. Please indicate one if you know it.
    Obviously there is no app that can retrieve mail during a phone call due to network limitations. But those limitations will soon be gone.

    My point is only that a good product must not change people settings but adapt to it.
    True for a good product; not so much for a great product. But we can agree to disagree about this.

    - Marc

    p.s. One difficulty I see with your approach (and that of TreoMail, for that matter) is the addition of (at least) two servers between the eMail host and your client on the Treo, namely: 1) your proprietary server which necessarily polls for new mail at some interval and 2) the network provider's SMS gateway (often more than one server involved). When "always on" becomes a reality, what would be the point of the additional overhead?
  8. #48  
    Originally posted by nfodor
    Now when it comes to single tasking I meant that I am still to see an email client on the Palm that lets you retrieve your mail on the background while you place a call or run another app. Please indicate one if you know it.
    Placing a call I can't answer, as that's more of a network limitation. But TreoMail does download mail in the background via a separate thread. Actually anyone can do that if they choose, it's not super-duper difficult.

    I had experimented with it in the past, but in order to answer your post, and my curiosity, I spent a few hours testing a multi-threaded approach in my GNUGotMail. To get it going, I just had to change some launchflags and comment out some UI code.

    I dunno. It's quite amusing to watch it do two things at once. But I'm just thinking the stability problems would be a nightmare.

    What you'll usually have is a background thread which is simply a SysAppLaunch w/ sysAppLaunchFlagNewStack|sysAppLaunchFlagNewGlobals|sysAppLaunchFlagNewThread. A lot of people don't realize that PalmOS allows multi-threads like this. The problems come about when you try to use any UI in your thread, which you really can't do without crashing & burning. So your background thread is pretty much stuck doing some non-visual stuff, and communicating somehow to your other thread.

    I don't know if there is some fancy way of communicating, but I did run into some peculiarities. My Mail stuff is split between a PalmOS Mail derivative and the GGM app. I use a launchcode to retrieve a shared dbref. During testing I noticed that I was unable to use a custom launchcode with the foreground application. It's as if my background thread was not aware of the "current" application and it instantiated another one which of course didn't give me back the correct stuff. Oh well I probably could have used a feature to share the dbref, but I only wanted to see it work in order to answer this post.

    If you watch the way that TreoMail does the background, they respect these issues as well -- in that the background thread is kept pretty basic. You will occasionally see a message popup when you try to turn off the device, saying that it is currently downloading mail etc. This message, I presume, is caused by their UI application which performs a test to recognize if their background thread is active, during a sleep request.

    Anyways, I haven't found a legit need for background threads yet in the way I use my device. I thought I wanted one, but it's too creepy. I'd rather not have the UI synchronization issues, and I like having a UI pop up when I do my triggered downloads, so I can cancel it if I want.
  9.    #49  
    Originally posted by snapperfish
    To qualify for the right to respond to this thread you need to have written an email client - so when are you releasing? (Kidding).
    I started it, so I have the right

    This is a very interesting discussion, I feel that the entire picture has not been taken into account.

    In the current state of things, data is not cheap. One can point out that Sprint is cheap, but the discussion ends there. GPRS is not cheap, at least not for the majority. One of the number one complaints of the Treo is battery life, and polling every 2 mins, or be continuously connected to servers is a big drain on battery.

    Full compliant IMAP, RFC etc. This can be interpreted so many ways. There are in production email servers that don't follow the RFC and that cause compliance issues between ISPs. This can be summed up that an email client can be designed to support whatever part of the RFC and what other features it wants, based on the developers perogative. As far as I can tell, Chatter uses IMAP as a connection protocol, and stops there. It does not implement any other features of IMAP, or other mail clients for that matter, nor is it designed to. I think implementing the unique connection that Chatter provides into a "fatter" client, would definately increase the data and decrease the battery life, as larger messages, attachments, folder syncing etc are added into the mix. As someone else has mentioned, IMAP servers aren't exactly plentiful. Most ISPs do not have them. Using a service like fastmail is a solution, but increases the overhead that poeple have complained about with Pushmail.

    With PushMail, that server can provide black/white lists. While in most fat clients, you can download the header and then choose to download more based on certain information, sender, subject etc. Setnet let's you do this in advance. Good for many.

    Marc, you brought up an interesting point regarding the addition of 2 servers between getting the message, the PushMail server, and the SMS gateway. The PushMail server is going be as reliable as any IMAP service. As I mentioned above, this is what most people, in my opinion, would be using. IMAP may be better for some, but ISP strategy is going to dictate this. Hence the reason that Snappermail does not, at present, have IMAP capabilties. The product has to appeal to the majority. The SMS gateway is supported by the wireless provider, can we not assume that this will be as reliable as the wireless connection? Maybe not as reliable as voice, but definately as data. At least the pushmail server is providing a valuable service: Controlling when and which mail reaches my handset, hence saving me data and battery life in un-neccesary connections.
  10. #50  
    Originally posted by nfodor
    Now when it comes to single tasking I meant that I am still to see an email client on the Palm that lets you retrieve your mail on the background while you place a call or run another app. Please indicate one if you know it.
    And my take on this.... Of course we can't have simultaneous phone call and mail download yet since the hardware doesn't support it but downloading mail in the background and running a forground app certainly can be done as has already been done.

    As potatoho mentioned Treo Mail does it. The first app on Palm OS to do it was MultiMail Deluxe on the i705.

    The Palm OS is multi-threaded. Yup.

    We got one thread running in the foreground that we all see.

    We got one thread running that just listens for Hotsync.

    We got one thread that... guess what? Handles TCP/IP.

    You can write an app that sets NetLib fetching and you can process it chuck my chunk periodically by patching the system with some cooperative multi-tasking code in the foreground.

    The hard part as potatoho says is doing it without messing up the UI. And also doing it without using up too stack space.

    SnapperMail architecture at 2.0 will be ready to do this magical background fetching but we really are beginning to doubt the payoff is big enough. Periodic fetching works fine right now and if we did this luxury, it will compromise stability by eating up stack space and OS6 will have multi-tasking for real so maybe it's just a lot of work for a limited window of opportunity.

    -W
    Will Lau


    www.snappermail.com

    A Killer Email Client for Palm OS Smartphones, now available...
  11. #51  
    Originally posted by snapperfish
    You can write an app that sets NetLib fetching and you can process it chuck my chunk periodically by patching the system with some cooperative multi-tasking code in the foreground.

    The hard part as potatoho says is doing it without messing up the UI. And also doing it without using up too stack space.
    That's kindof the approach that a keyboard driver would use. I've seen them trap EvtGetEvent() and override the timeout parameter so that nilEvents occur at small intervals, and those are then used to "poll" the NetLib.

    But my example was actually using a separate thread, stack, and globals. It runs concurrently with its own event loop etc. But it cannot be a UIApp because that just freaks it out. Furthermore, some API must be made from the UIApp and so you have to take that into account.

    My personal approach has been to launch with new stack, globals, but not use the UI flag. Then I save/restore the UI state myself, and make my own form handler active. This makes my SMS triggered downloading session occur in a type of popup (though it isn't actually a modal form), which when completed or user-canceled, disappears and your UI state is unchanged; i.e. it doesn't ever close the default application. I've honestly been very happy with the approach, as it is a compromise between fully background and interactive.
  12. #52  
    Originally posted by Appleman


    <snip>

    Full compliant IMAP, RFC etc. This can be interpreted so many ways. There are in production email servers that don't follow the RFC and that cause compliance issues between ISPs. This can be summed up that an email client can be designed to support whatever part of the RFC and what other features it wants, based on the developers perogative. As far as I can tell, Chatter uses IMAP as a connection protocol, and stops there. It does not implement any other features of IMAP, or other mail clients for that matter, nor is it designed to. I think implementing the unique connection that Chatter provides into a "fatter" client, would definately increase the data and decrease the battery life, as larger messages, attachments, folder syncing etc are added into the mix. As someone else has mentioned, IMAP servers aren't exactly plentiful. Most ISPs do not have them. Using a service like fastmail is a solution, but increases the overhead that poeple have complained about with Pushmail.

    With PushMail, that server can provide black/white lists. While in most fat clients, you can download the header and then choose to download more based on certain information, sender, subject etc. Setnet let's you do this in advance. Good for many.

    Marc, you brought up an interesting point regarding the addition of 2 servers between getting the message, the PushMail server, and the SMS gateway. The PushMail server is going be as reliable as any IMAP service. As I mentioned above, this is what most people, in my opinion, would be using. IMAP may be better for some, but ISP strategy is going to dictate this. Hence the reason that Snappermail does not, at present, have IMAP capabilties. The product has to appeal to the majority. The SMS gateway is supported by the wireless provider, can we not assume that this will be as reliable as the wireless connection? Maybe not as reliable as voice, but definately as data. At least the pushmail server is providing a valuable service: Controlling when and which mail reaches my handset, hence saving me data and battery life in un-neccesary connections.
    I agree with most of your assessment . However, I have found that most production mail servers that implement IMAP4 are, in fact, RFC compliant with regards to the key provisions. The most important thing that people seem to miss at the client side is the synchronization capability as outlined in the specification. This was one of the main purposes; maintain a common message store where access can be gained from any device supporting IMAP and the resultant message folders are the same all of the time. Without the synchronization capability, it is a real stretch to say a client (any client) supports IMAP.

    IMAP is popular for corporate users again because of the ability to access a common message store from any device from anyplace. I agree from an ISP perspective, a better solution may be web-based e-mail and several ISP's are going that way. I believe, in time, POP will go away. It just doesn't make sense to have messages on a desktop, different messages on a PDA, laptop, home, etc. and POP isn't a good platform to support this requirement.
Page 3 of 3 FirstFirst 123

Posting Permissions