Page 2 of 3 FirstFirst 123 LastLast
Results 21 to 40 of 52
  1.    #21  
    [QUOTE]Originally posted by dennis3232
    Did anyone try 2bAnywhere (2banywhere.com)?
    It's a genuine pull mail that works with Hotmail/SMS as well as POP3 and IMAP4.
    The beta version is free and their help desk is efficient and quick to answer.
    I have been using them for months now and I am quite happy.


    Most mail clients are "genuine pull", everyone here wants genuine push, without the hassles that all the current solutions provide.
  2. #22  
    Originally posted by Appleman Most mail clients are "genuine pull", everyone here wants genuine push, without the hassles that all the current solutions provide. [/B]
    Please explain for all those phillistines out there...
  3. #23  
    Let me explain couple of things about
    SMS push in general and SetNet Pushmail
    in particular:

    First of all there is no 200% overhead somebody mentioned in this thread. SMS is sent once per polling period, not once per message. SMS does not contain actual message, just indication there is one.

    Some people mentioned that GPRS connection could be used to simulate push. It may very well be used for that, but main problem with that approach is that your phone CPU should be constantly on to receive "push". That will bring down your battery life to pretty much nothing.

    The beauty of SMS approach is your Palm part of Treo is constantly in "sleep" mode while radio part is awake (it is always is when you want to receive calls). When SMS arrives it wakes up Palm part. We predict huge battery savings when compared with pulling approach (TreoMail even gives you warning on that if you set polling more frequent than certain value).

    There are couple other features I would like to mention:

    1. With pushmail you can access multiple accounts, including HotMail. You can define different notification schedules for different accounts.

    2. PushMail have server side component converting your messages to format sutable for browsing on your palm. For beta servive we are running simple version which just stips attachments. If you think about all money you pay on your GPRS traffic downloadin office email with huge attachement you will appreciate this feature as I do. I did calculations for my mailbox: to download all my mail on Treo w/o server side transformation would cast me several hundreds dollars of GPRS traffic each month. With PushMail I am staying with 4Mb easily.

    3. We have spam filterting. It works very well.

    The service is currently free and I encourage everybody to give it a try. We are very attentively listening to customer remark and wil work hard to make this product even better.

    Sincerely,
    Vadim

    P.S. I work for SetNet and will be glad to answer your questions. Once you register at http://service.setnet.com/ you will get access to our internal support forums where you can find more information and answers to your questions. Not to pollute this forum it is better to ask your support questions there.
  4. #24  
    GPRS or G3 (i.e. Treo 300) can be used to push eMail; there's no simulation about it. Chatter's IMAP eMail is as close to pushed as you can get, directly from the eMail server (i.e. rather than through a proxy that polls the eMail server). Again, Chatter is NOT primarily an eMail app, but it's wrong to say that pushed eMail can only be simulated using a GPRS/G3 service.

    What's more, besides eMail, I get IM's and IM presence information literally pushed to my Treo all the time. I send/receive many dozens of IM's per day, in addition to receiving dozens of eMails and sending a few. I can run all day on a battery charge with no problem. I don't know why you think this is impossible or that it requires the CPU to be on all of the time; it doesn't Battery life is far more related to radio usage than "Palm" usage anyway. I think that "huge" savings aren't in the cards, although it's possible that some savings will be seen.

    BTW, you indicate that you send SMS once per polling period. Probably you should indicate what the polling period is, so that it might be compared with other options.

    - Marc
  5. #25  
    Originally posted by mblank

    BTW, you indicate that you send SMS once per polling period. Probably you should indicate what the polling period is, so that it might be compared with other options.
    - Marc
    Polling period is choosen by user, on the server side. It could be set per account, time interval and day of week.

    SMS is sent not each polling period, but only
    if new mail is detected.

    Sincerely,
    Vadim
  6. #26  
    I would like to bring my 2 cents to this conversation and explain further SetNet philosophy when it comes to wireless email in general and the Treo more specifically.

    I don't believe that the issue is only a matter of push or not push, there is more to it.
    In today's world enhancements to existing technologies must be based on open protocols and open technologies. Wireless technologies allowing practical email are independent from the device one can choose. The Treo may well be the most practical handset on the market because of its underlying popular operating system, Palm but also to it's easy input capabilities, a real keyboard, and small form factor. But the Treo would be worth very little if it was not for its ability to connect to the so called 2.5G networks and their added flexibility when it comes to throughput and billing flexibility.
    The reality is that the 2.5 G networks, GPRS and 1 XRTT, widely available today, are far from being perfect. First their quality varies depending where you are connecting from and sometimes how fast you move across the coverage area. Also it is not, definitely not, a true "always on" IP connectivity.
    Even though it's technically possible to "ping" a phone, it would require 2 things to happen, first it must be always on, meaning having a socket listening on a continuous basis. This would drain the battery and make the device unusable in no time. Second, most operators use NAT translation which mean that the phones, even if they were always on would be protected against flexible incoming connections.
    Also, and mostly, the only way to economically wake up a phone in "sleep mode", meaning not emptying its battery in 2 hours, is by contacting it through SMS. Why is that so ? Because SMS acts at the radio level and is necessarily on at all time because it is carried by the same network protocol that allows carriers to route calls to the handset. This protocol is called SS7 and it is very solid since a very long time.
    There are other ways to achieve always on with a mobile device, through a mobile radio network, such as Mobitex. Dedicated mail devices such as the good device and most Blackberry devices currently use these protocols, even though RIM, maker of the Blackberry does support GPRS now.

    The only alternative to waking up the phone is for the phone to regularly connect at pre-defined interval and check if there is new mail. There is nothing wrong with that method, if such is the user's choice and can be mixed with other "wake-up" technologies as a back-up plan.

    But that is not the only problem to be solved when it comes to wireless email. In fact that is not a problem at all once a way exists, and it does, to wake up the handset. The real problem is the high cost and low speed of data transmission.

    Wireless data is not cheap, it's very expensive when compared to your plain modem connection, at least in the US, ADSL, or a T1.
    Most mobile users who want email when on the go are depending on email, if not they would wait to be back at the office or at home. This means that they have lots of email for most of them. And that includes not only lots of expected email but SPAM as well. Some recent numbers show that 45% of people's mailbox is SPAM in average.
    So a proper wireless email technology, one that takes care of SPAM, and makes sure that messages above a certain size don't get downloaded, or better get transformed to be still readable but in smaller size is an absolute requirement in order to bring the bandwidth down. The other positive aspect of such a mail box filtering policy, and the volume reduction to be transferred on the handset as a consequence, is to provide shorter mailbox download time. Have you ever tried to download a 4Mb Word document on a modem line with a laptop ? With GPRS and 1XRTT one is lucky if it gets even closer from that speed.

    Any client on the Treo will not be capable to prepare a mailbox to be wireless compliant, meaning making it lean enough so it does not trigger long and costly download time. This is a backend work, it needs to be done before the mail client has access to the original mailbox. What good is filtering on a handset mail client if first all messages need to be downloaded to be filtered and SPAM processed; it's already too late.

    So what we have tried to achieve at SetNet is to make the backend as powerful as possible so as to make the client work as little as possible. Also since more and more users are now using laptops and are not necessarily in control of a server, we have designed the pre-processing of messages as a service so one does not have to worry about running yet another software to do so.
    We have added very tough requirements when it comes to quality of service. Meaning we believe that a well maintained service will always provide up time so email can always be processed.

    Now about the client. At SetNet we are not trying to impose a new Palm mail client on the market. We believe we had to come out with a client, neatly adapted to the specific push context because there was a need for one. But we also believe that any one who likes his email client needs to have the choice to keep it. And we are soon adding to our service the ability to use any email client and still benefit from server side SPAM, rule and content transformation processing. More, very soon, on this topic.

    If you have read this posting until this point I would like to thank you for doing so and I hope it was good use of your time. Your feedback is greatly appreciated and if you want to give our service a try you?re welcome to do so. The address is http://service.setnet.com . You will be able to use your Treo and once your account has been created we will also provide you with other neat services in the coming week so you can benefit from wireless email pre-processing features not only with our mail client but also with 3rd parties and non-Treo handsets.

    Nick Fodor
    Founder and CTO
    SetNet
  7. #27  
    Even though it's technically possible to "ping" a phone, it would require 2 things to happen, first it must be always on, meaning having a socket listening on a continuous basis. This would drain the battery and make the device unusable in no time. Second, most operators use NAT translation which mean that the phones, even if they were always on would be protected against flexible incoming connections.
    Also, and mostly, the only way to economically wake up a phone in "sleep mode", meaning not emptying its battery in 2 hours, is by contacting it through SMS.
    This is demonstrably untrue.

    As I said before (please re-read it), I send and receive dozens of IM's, IM presence packets, and eMails without resort to using SMS, and I have no problem running for all day long on my Treo's batteries.

    The only alternative to waking up the phone is for the phone to regularly connect at pre-defined interval and check if there is new mail. There is nothing wrong with that method, if such is the user's choice and can be mixed with other "wake-up" technologies as a back-up plan.
    Also demonstrably untrue. I receive mail all day long without making and breaking connections. The mail is pushed to the phone by the email host.

    Wireless data is not cheap, it's very expensive when compared to your plain modem connection, at least in the US, ADSL, or a T1.
    This is also not true for some carriers. Sprint (Treo300) comes to mind with unlimited data for $10/month. That's hard to beat.

    Any client on the Treo will not be capable to prepare a mailbox to be wireless compliant, meaning making it lean enough so it does not trigger long and costly download time. This is a backend work, it needs to be done before the mail client has access to the original mailbox. What good is filtering on a handset mail client if first all messages need to be downloaded to be filtered and SPAM processed; it's already too late.
    But many people have their POP3 or IMAP hosts already filtering out spam at the mail host. As you say, this is a server-side issue.

    Believe me, I have no complaint at all about your product and service. But if you're going to make blanket statements about what can and cannot be done using TCP connections on 1XRTT/GPRS devices, you should at least get the facts straight.

    - Marc
  8. #28  
    Originally posted by mblank
    (re: socket listening .. empty battery .. 2 hours) This is demonstrably untrue.
    While I don't fully agree with nfodor's blanket statement, I can confirm it in practice It takes only a 60 second window of coverage flakiness to cause the Treo 300 radio firmware to freak out in numerous ways.

    I take it you've not yet experienced the turbo drain (battery dead in an hour), or red blink of death (signal lost until paper-clip reset)

    It must be related to tower issues. It's just getting worse and worse for people. Strangely, I'm feeling completely liberated now that, in practice over the past few days, I've worked-around the turbo drain issue.. and yet still have daily red blinks of death. At least my phone isn't getting burrito hot and spiralling into the red zone within an hour. Yay!
  9. KKenna's Avatar
    Posts
    418 Posts
    Global Posts
    419 Global Posts
    #29  
    OK, this is the best thread I've participated in so far.

    I'd like to back off the focus of the post to ask a few more questions (well, one at least).

    So far, all I've heard are reasons why "true push" won't work or would be cost prohibitive. If the 1xRTTT / GPRS networks are supposed to be more advanced, then why can a technology from 5 years ago (Blackberry / Mobitex network) beat it hands-down for reliability and delivery speed (I have already anticipated some of the responses, but am playing devil's advocate).

    If there are so many problems with TCP sockets or IP addresses being in fake-space, why not think outside the box and have an e-mail client, or desktop "assistant" that pushes via an ESN. My point is, if I can call a carrier and have them almost pinpoint my location, or get them to program my phone over the air, or receive an SMS message in seconds, why does e-mail present such huge obstacles on the new networks ? Basically, you have a radio device that is always available (as long as you're in a coverage area). It can be addressed in numerous ways. Why is e-mail such a hard solution to implement ?

    As far as the SPAM filter goes, this is a nice option, but those of us who rely heavily on e-mail have long-since installed filtering sofware (I'm using Qurb, http://www.qurb.com, and NEVER get a single piece of SPAM in my INBOX). IMHO, we have enough options for triggered SMS. Why not come out with something that will actually provide some choice in the market.

    I suppose all of this will become mute with the next-gen networks that Verizon has already announced. Once Sprint actually gets 1xEvDv up and running, we won't need to worry about push vs pull. We'll just log in and stay connected.
  10. #30  
    The two problems with TCP today are both due to two related near-term problems: 1) The GPRS/1xRTT networks are really "mostly on", rather than "always on" and 2) Voice and data connections cannot be maintained at the same time.

    Once this (these) problems are addressed (I'm thinking later this year), there really will be little use for SMS-based applications.

    The push vs. pull question, as addressed here, is largely irrelevant. The real issue, in my mind, is whether the eMail client is working directly with the eMail server (i.e. without a proxy, as is the case with TreoMail, PushMail, etc.) And the solution to this would be ubiquitous use of IMAP, which was designed for persistent connections and server-side processing, rather than POP3, which is as old and musty as SMS.

    I use Chatter for most eMail on my Treo because the eMail is pushed, because it is always (limited by carrier) connected, and because the heavy lifting (i.e. spam filtering, etc.) is carried out by my IMAP host. The approach is, I believe, the only viable one in the long term, although the actual software is light on eMail features by design (SnapperMail being my preferred "heavy" client).

    - m
    Last edited by Chatter; 03/17/2003 at 09:46 AM.
  11. #31  
    Just tried to sign up, but England doesn't appear to be supported yet. Anyone know if there are plans to do this? Sounds like a nice app.
  12. #32  
    Originally posted by bigruss
    Just tried to sign up, but England doesn't appear to be supported yet. Anyone know if there are plans to do this? Sounds like a nice app.
    What carrier you are using? Do they have email->SMS gateway?
  13. #33  
    Hi Nick, Hi Mark,

    May I congratulate you guys both on coming out with a product that delivers what you both set out and believe in. (Especially Mark on his magical Chatter app which pulls off what many though was impossible). This is indeed an interesting discussion. I thought I'd throw my 2 cents into the pot too...

    On the whole I like Mark's approach and it's similar to ours which has resulted in SnapperMail.

    Nick mentioned:

    Wireless data is not cheap, it's very expensive when compared to your plain modem connection, at least in the US, ADSL, or a T1.
    I tend to agree with Mark 200% here. Wireless data is getting cheaper by the month - $10 unlimited at Sprint? If that aint cheap I don't know what is. This leads me into the crux of what SnapperMail is all about.

    When we laid the ground rules for Snapper a long long time ago - Q4 2001 infact. Snapper would be a long gestation project, so we pitched the architecture at a moving target. We made assumptions about the wireless space that we'd live in 2-5 years into the future i.e. 2003-2005. What we saw was:

    (1) Very cheap and plentiful bandwidth
    (2) Plenty of CPU and storage
    (3) Large adoption of standard wireless protocols (GPRS and 1xRTT) - more improvements to come.

    With that in mind we decided to build a FAT client with layers upon layers of code that would - by the end of its development - rival a full desktop client in capability e.g. Outlook Express. We did a lot to things including our own memory management (compression capable), a true MIME database structure that allows archiving of up to 4GB of mail onto a memory card, modular comms layers, hooks into future OS features, unlimited hierarchial folders, etc, etc. And thus Snapper was created - it's underlying architecture still remains true to this.

    Back then we thought that anything relying on proprietary thin proxy technology would approach obsolence by the end of 2003. My views still haven't changed much.

    With push technology, we believe that as protocols and hardware improve, push will be part of the OS. I tend to think there will be a day coming soon when the hardware will wake our comms layer up to a full fetch. I even think that our comms code with run in a low power sleep state and will talk to our UI layer through an object exhange when it's done. Generally adopted standards, protocols, and hardware will dictate the future.

    To me, PushMail is a triggered pull system (periodically polled at the proxy) that works around battery consumption issues by using a proxy service.

    -W
    Will Lau


    www.snappermail.com

    A Killer Email Client for Palm OS Smartphones, now available...
  14. #34  
    I truly enjoy this thread. And I am learning something too. In the long run, I hope, this kind of chat will help improve the Treo (does anyone at HS read this?...)
    m00se
    I have never let my schooling interfere with my education.
    -Mark Twain
  15. #35  
    Thanks for the input, Will.

    My hope, as you know, is that Chatter (a contact based messaging app) and SnapperMail (full service eMail client) will eventually be able to work together seamlessly.

    - m
  16. #36  
    Originally posted by snapperfish
    Hi Nick, Hi Mark,

    May I congratulate you guys both on coming out with a product that delivers what you both set out and believe in. (Especially Mark on his magical Chatter app which pulls off what many though was impossible). This is indeed an interesting discussion. I thought I'd throw my 2 cents into the pot too...

    On the whole I like Mark's approach and it's similar to ours which has resulted in SnapperMail.

    Nick mentioned:



    I tend to agree with Mark 200% here. Wireless data is getting cheaper by the month - $10 unlimited at Sprint? If that aint cheap I don't know what is. This leads me into the crux of what SnapperMail is all about.

    When we laid the ground rules for Snapper a long long time ago - Q4 2001 infact. Snapper would be a long gestation project, so we pitched the architecture at a moving target. We made assumptions about the wireless space that we'd live in 2-5 years into the future i.e. 2003-2005. What we saw was:

    (1) Very cheap and plentiful bandwidth
    (2) Plenty of CPU and storage
    (3) Large adoption of standard wireless protocols (GPRS and 1xRTT) - more improvements to come.

    With that in mind we decided to build a FAT client with layers upon layers of code that would - by the end of its development - rival a full desktop client in capability e.g. Outlook Express. We did a lot to things including our own memory management (compression capable), a true MIME database structure that allows archiving of up to 4GB of mail onto a memory card, modular comms layers, hooks into future OS features, unlimited hierarchial folders, etc, etc. And thus Snapper was created - it's underlying architecture still remains true to this.

    Back then we thought that anything relying on proprietary thin proxy technology would approach obsolence by the end of 2003. My views still haven't changed much.

    With push technology, we believe that as protocols and hardware improve, push will be part of the OS. I tend to think there will be a day coming soon when the hardware will wake our comms layer up to a full fetch. I even think that our comms code with run in a low power sleep state and will talk to our UI layer through an object exhange when it's done. Generally adopted standards, protocols, and hardware will dictate the future.

    To me, PushMail is a triggered pull system (periodically polled at the proxy) that works around battery consumption issues by using a proxy service.

    -W
    Hello Will, happy to see you around. There would be no complete thread without the Snaperfish man himself. Your product is really pretty. And you're right it's a fat email client.
    We provide immediate email. The only way to do that with Mail clients would be to poll every 3 minutes at least, and I believe that SnapperfishMail recommends not to do so in order to conserve battery.

    You're saying that in the future we will not need to wake up the phone through transparent and hidden coded SMS, that's good, we all wait for this to happen. The question is: What do we use now for email when we don't want to wait for 30 minutes for each poll ?

    I guess we don't, or we use SetNet PushMail for the Treo Service. Then when the new technology comes out one day, that allows to avoid non IP based handset wakeup (Not that the users really care, after all it works) we will be able to do without SetNet PushMail service.

    When it comes to Chatter, why don't we digg a little in how immediacy happens, the product is not ready for public beta, so I guess we will need some help from its programmer, Mark (mblank).

    (Stay tuned...)
  17. #37  
    We provide immediate email. The only way to do that with Mail clients would be to poll every 3 minutes at least, and I believe that SnapperfishMail recommends not to do so in order to conserve battery.
    PLEASE stop telling half-truths! What you say is true of POP3 eMail clients in general, but it's demonstrably untrue with IMAP clients.

    IMAP is designed for persistent connections, and can push new status information through TCP connections. There are lots of IMAP hosts around; the one I recommend is www.fastmail.fm Their IMAP service is free; use of their SMTP server for outbound messages costs something like $15 per year.

    There's not a question in my mind that IMAP is the best choice for users with more than one device accessing their eMail. I, for one, can't wait until SnapperMail supports it.

    -m
  18. #38  
    Originally posted by mblank


    PLEASE stop telling half-truths! What you say is true of POP3 eMail clients in general, but it's demonstrably untrue with IMAP clients.

    IMAP is designed for persistent connections, and can push new status information through TCP connections. There are lots of IMAP hosts around; the one I recommend is www.fastmail.fm Their IMAP service is free; use of their SMTP server for outbound messages costs something like $15 per year.

    There's not a question in my mind that IMAP is the best choice for users with more than one device accessing their eMail. I, for one, can't wait until SnapperMail supports it.

    -m

    IMAP: It is an optimized protocol allowing to check email online and retrieve locally only the pieces one need. So from that perspective if you want your message on the fat client, you still need to retrieve it and it will not make the message smaller then POP. And you still pay for the price for slowness while retrieving the message.
    During that time your palm is single tasking.

    But again, IMAP has NOTHING TO DO with being immediately notified of new messages in a wireless optimized manner. I understand that with IMAP you can keep the connection up and that there is a built-in protocol for sync, but then you do need to be always on, which is exactly what SetNet PushMail is trying to avoid.

    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. That is also why PushMail works directly with one's mail account, and more without the need to have an IMAP account.
    Most ISP and web mail do disable IMAP accounts because it cost them too much to keep mail for their customers.
    Yahoo does not support IMAP, same for HotMail right there you have more then 250 millions email address.
  19. #39  
    Wrong, wrong, wrong. And it's becoming exasperating.

    IMAP: It is an optimized protocol allowing to check email online and retrieve locally only the pieces one need. So from that perspective if you want your message on the fat client, you still need to retrieve it and it will not make the message smaller then POP.
    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?)

    And you still pay for the price for slowness while retrieving the message. During that time your palm is single tasking.
    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.

    But again, IMAP has NOTHING TO DO with being immediately notified of new messages in a wireless optimized manner. I understand that with IMAP you can keep the connection up and that there is a built-in protocol for sync, but then you do need to be always on, which is exactly what SetNet PushMail is trying to avoid.
    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.

    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.
    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
  20. #40  
    Man, there is a lot being thrown around regarding IMAP. Some of it is accurate and most of it is not. Just to establish a common definition of IMAP; RFC 2060 the IETF standard, it is located here. 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.
Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions