IMAP... Komoly. Ha tényleg így van, akkor az MS-nél ideje lenne talán átgondolni, hogy nem mindig az a legjobb, ha az ő saját megoldásaikat erőltetik - ez a spanyol viasz dolog nem is olyan nagy hülyeség. Viszont így akkor hetekig, hónapokig eltart, mire javítják.

Na tegnap meg még a yahoo volt a hibás. Nem lehetne hogy leül a 2 fejlesztő csapat és megírnák rendesen?

Én kibacnék vele, mert azonnal tiltok mindent ami mobil net mivel nem lehet megfizetni, max havi 20 megásat tudnék elképzelni. Aki ilyet vesz az gondolom én nem csóri és tudja fizetni a mobilnetet is, tehát semmi gond itt.

Jaja csak mintha azt írták volna valahol hogy a (l)userek kiszaladtak a 2gigás csomagból nem kicsit emiatt a remek IMAP protokoll miatt. A napi több tíz mega lehet 50-90 mega is....

Nem dohányzom köszönöm.

márpedig eddig úgy tűnik, hogy jól csinálja, mert simán küld egy FETCH kérést a szervernek.

alapesetben ez a válasz:

* 1 FETCH (UID 258 BODY[HEADER.FIELDS (MESSAGE-ID)] {81}
Message-Id: [contoso194089-0-1475496219-3-11262342655328369@CONTOSO.COM]
FLAGS (XAOL-RECEIVED XAOL-GOOD XAOL-GOODCHECK-DONE XAOL-CERTIFIED-MAIL XAOL-BILLPAY-MAIL $hasEmbedded))
…
OK FETCH completed

a Yahoo! pedig ezt a választ küldi:

X-YMAIL-UMID: 1_1231_AH9SAiosajdifsLGYp8
Delivered-To: rafael@withinwindows.com
Received: by 0.0.0.0 with SMTP id b14cs36932vcd;
Wed, 24 Nov 2010 09:48:20 -0800 (PST)
[snipped]
Received-SPF: pass (google.com: domain of bxp60spbgycisj582h2kt@contoso.com designates 0.0.0.0 as permitted sender) client-ip=0.0.0.0;
DomainKey-Status: good (test mode)
Authentication-Results: mx.contoso.com; spf=pass (contoso.com: domain of bxp60spbgycisj582h2kt@contoso.com designates 0.0.0.0 as permitted sender) smtp.mail=bxp60spbgycisj582h2kt5hjwxuss6f@contoso.com; domainkeys=pass (test mode) header.From=dummy@contoso.com
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=200505; d=email.contoso.com;
b=[snipped]+CKirfbuapQiU=;
h=Date:Message-ID:List-Unsubscribe:From:To:Subject:MIME-Version:Reply-To:Content-type;
Date: Wed, 24 Nov 2010 17:48:39 -0000
Message-ID: [bxp60spbgychw1axh2kt.7412145937.3427@MTA915.CONTOSO.COM]
List-Unsubscribe: [mailto:rm-0bxp60spbgychw1axh2kt@EMAIL.CONTOSO.COM]
From: “Contoso” [dummy@EMAIL.CONTOSO.COM]
To: rafael@withinwindows.com
Subject: This is a test message
MIME-Version: 1.0
Reply-To: “Contoso” [dummy@EMAIL.CONTOSO.COM]
Content-type: multipart/alternative; boundary=”=bxp60spbgychw1axh2kt5hjwxuss6f”
…
OK FETCH completed

egyébként meg iPhone-t is érinti, szóval nagyon úgy néz ki, hogy a Yahoo!-nál van a probléma.

félreértés ne essék, Yahoo! Mail-t jelenleg a legtöbben használnak, maximum a WP7 userek közül nem sokan.

Mi generál forgalmat? Ha van forgalom gondolom célja van hacsak nem levelezik egymással a teló meg egy szerver, hogy milyen az idő nálatok.

Mert talán a két válasz közötti méretkülönbség okozza a gigabyteokat?

A bug addig bug amíg nem dokumentálják, onnantól feature.

Nekem Yahoo-m van iPhone-on és semmi gondom nincs vele.

@ Nokia Lumia 1520 Black @

ha minden üzenetváltás a telefon és a Yahoo! mail szerver között 25-szörös adatforgalmat generál, akkor abból elég könnyű kiszámolni.

IMAP módban? akkor bizony több forgalmat generál, mint kéne. lehet, hogy nem veszed észre, mert annyit nem forgalmazol rajta, hogy kiütközzön.

Ezt - gondolom - akkor kérdezi végig, amikor először szinkronizálja magát az IMAP szerverrel és ezt végignyomja minden üzenetre (mondjuk akkor meg nem értem, hogy miért nem range-t kérdez le, szóval lehet, hogy nem pont erről van szó, csak kb ). Ha csak pár email van az inboxban, akkor nem vészes a dolog, de ha sok év milliónyi levele, akkor már gond van.

szerk: most látom, hogy refreshnél is ezt csinálja - az mondjuk nem tiszta, hogy miért nem inkább SELECT-et nyom, de hát nem én írtam a klienst

[ Szerkesztve ]

DRM is theft

Talán ez lehet az, amiben az MS eltér a Google megoldásától - a lekérdezés mikéntje és nem maga a lekérdezés. Az elég gáz, ha mindig minden levélnél külön csesztet és nem csak az újakat veszi elő. Amúgy meg akkor adnának ki valami közleményt, hogy ne használjon IMAP-ot a nép, ha már ennyire tudják, hogy az a baj.

Biztos titokban fotoz es rogziti a tartozkodasi helyunket es kuldi el az ms-nek, akik zsiros penzekert tovabb adjak a maffianak.

https://www.youtube.com/watch?v=mkDSGbRyjz8&list=PLVJH24yGtE_w5Ke4aWmRV8erFQmqRD1dK Minden egyes új rész rátesz még egy lapáttal :-D

Kiszámoltam: az általad mellékelt kód 11k, az eredeti cikk óránként 2 megabyte-ot említ, tehát ennek a kódnak óránként 186-szor kellene átmennie, ami percenként kb. 3 lekérdezést jelent. Nekem még a pc-m is csak 5 percenként kéri le a leveleimet, szóval önmagában a válasz mérete nem indokolna ekkora háttér-adatforgalmat.
A másik, hogy hibaként említették azt is, hogy a wlan meglétekor is 3g-re megy a teló. Ez pedig nem lehet a válasz hibája, mert a válasznál már a kapcsolat kialakításra került.

A bug addig bug amíg nem dokumentálják, onnantól feature.

a WLAN-3G hibát aláírom, ettől már a régi WM is szenvedett, de a mail kezelés szerintem minimum két szereplős történet, de biztos, hogy nem kizárólag az MS hibája.

Most akkor mégsem 3. fél? Jöttek a beírások hogy azért nem adja ki a MS ezt a partnert, mert nem akarja elveszíteni...stb, de ezek szerint szimplán nem volt igaz amit mondtak.

Simán lehet, hogy azt hitték elsőre, hogy Yahoo, de a Yahoo megnézte jobban és MS

Azért LOL, hogy még mindig csak feltételes módban találgatnak

aztán ha még ennél is jobban megnézzük, kiderül, hogy mégiscsak Yahoo.

"The iPhone does have the same problem, but it’s less visible. Because it sends the FETCH command for only 50 messages at a time, compared to the 200 on Windows Phone."

#31: már rég dolgoznak a hiba elhárításán. az update-ben benne is lesz.

[ Szerkesztve ]

ez itt iPhone-os példa, sehol egy WP7.

mi az, hogy hiteles-e? milyen oldalról? az ott egy iPhone-ról származó napló, szerinted ha egy Apple-fan oldalon jelenik meg, akkor más lesz vagy rövidebb? most komolyan...

az is le van írva, hogy iPhone-on miért nem annyira szembeötlő: mert csak az utolsó 50 üzenetet nézi, a WP7 pedig az egész inboxot.

[ Szerkesztve ]

"Nekem azért nem tetszik, mert pont egy mictosoft fan oldal"
bocs, de ennél röhejesebb érvelést nem hallottam még.

"Kiderült a wp7 kapcsán ez "bug", de az iOS-nél meg most, 2008 óta? A világon a legnagyobb figyelemmel kísért platformon most veszik észre? Ő az egyetlen ember, aki a sok geek, szakember közül észre veszi?"

Valószínűleg eddig a kutya se nézte, most meg bárki leellenőrizheti és senki se mondta, hogy ne ezt látta volna.
Egyébként valószínűleg azért most bukott ki, mert a Yahoo egyértelműen bugos megoldása találkozott a MS idióta megoldásával és a kettő szinergiája tette igazán durvává a hibát

DRM is theft

mennyivel idiótább az MS megoldása, mint az Apple-é, ha ugyanazt az eredményt produkálják?

"Because it sends the FETCH command for only 50 messages at a time, compared to the 200 on Windows Phone."

DRM is theft

ez csak annyit jelent, hogy az utolsó 200 üzenet frissességét néz 50 helyett. ettől még ugyanúgy mindkettő rossz választ kap.

De mi a halálnak néz meg annyit? Most komolyan, mi értelme van ennyit fetchelni?

DRM is theft

lehet, hogy soknak tűnik - Exchange-nél ugye lehet konfigurálni, hogy mennyi időre menjen vissza - de ha valami szarul működik, arra szerintem az rossz válasz, hogy minek használod.