• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: mail-in db/app
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mail-in db/app


  • Subject: Re: mail-in db/app
  • From: Uli Kusterer <email@hidden>
  • Date: Tue, 2 Oct 2007 11:33:05 +0200

Am 02.10.2007 um 10:31 schrieb René v Amerongen:
Op 2-okt-2007, om 10:01 heeft Uli Kusterer het volgende geschreven:

Am 01.10.2007 um 20:48 schrieb René v Amerongen:
Just POP3.

POP3 itself is pretty easy. It's a protocol that was designed to be typed in manually by humans, and hence, it's pretty easy to just look at the POP3 RFC documentation and write your app to send/ receive the command. The thing where it becomes difficult is parsing the actual messages themselves: The RFC 822 message format and its extensions (MIME etc.) are quite involved, and if you want to handle all that correctly, you'll have a bunch of work ahead of you. If you want to also handle all messages that some of the less standards-compliant mail clients may throw at you, you'll have even more work.

Text and url pointers to get extra information about where to get blobs ( also in an separated thirt thread ). But the url's are of course just text.

I don't understand what you mean here... if you are talking about loading additional resources linked to from HTML e-mails, yes, that could be an additional thing to do, but you could also just use WebKit to display those, maybe with a custom URL loader that allows referencing images attached to the message using relative URLs. MIME is how attachments are stored.


For cocoa, I did found only pantomine, and that's to heavy.

Well, it's intended to be used for cloning an application like Mail.app, and last I checked, PantoMIME was very lightweight if you considered that.

Hmmm, maybe I could use a part of it. I will check the licence.

IIRC it's LGPL.

That makes reading/writing much more convenient. I just wrote myself wrappers for line-wise reading of ASCII strings and put them in an object of my own that owns the NSFileHandle. Worked beautifully. Also, keep in mind to do all this stuff on a second thread,

I did prepare that already, but I dont know why, but I have scary feelings about how to pass through the handle or socket to another thread to follow the input and output stream, like in the image at http://krum.rz.uni-mannheim.de/inet-2003/ -=> sockets -=> Pic. E

That picture is about using Java and sockets to communicate between two applications. Nothing is being passed around there. You said you wanted to implement a POP3 client, so you only need to handle one half of this diagram. It's really easy, trust me. Just start a new thread, and have that create the socket and file handle, and use the blocking I/O code in NSFileHandle. Since this is a separate thread, it's OK to block, because control will be given back to the main thread while you're blocking.


The only thing where you have to be careful is when you give back the received data to the main thread (e.g. add the e-mail object you created to your array of messages in the inbox). In that case, you need to either do this on the main thread, or use a lock of sorts (NSLock or @synchronized or whatever), so you don't try to insert something in the array in one thread while your UI thread is iterating over the message list. The easiest way is probably to just use performSelectorOnMainThread to pass a "message" object to the main thread and have it added there.

so the user can use the GUI even while you're downloading e-mail.

That said, there's a couple of URL connection and socket classes out there that might also be handy.

I will search for them

I think I used NetSocket once, which was kind of OK. But really, you only really need those if you want to implement a server, or if you're really scared of sockets. But If you're implementing a client, it's pretty straightforward to just connect to a particular host at a particular port (all the complicated threading and forking is happening on the server side, completely transparently for you), you get back a file descriptor, and then you create an NSFileHandle for that, and use it to write your requests and read the answers, line-wise.


Cheers,
-- M. Uli Kusterer
http://www.zathras.de



_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >mail-in db/app (From: René v Amerongen <email@hidden>)
 >Re: mail-in db/app (From: "I. Savant" <email@hidden>)
 >Re: mail-in db/app (From: René v Amerongen <email@hidden>)
 >Re: mail-in db/app (From: Uli Kusterer <email@hidden>)
 >Re: mail-in db/app (From: René v Amerongen <email@hidden>)

  • Prev by Date: Re: mail-in db/app
  • Next by Date: Re: mail-in db/app
  • Previous by thread: Re: mail-in db/app
  • Next by thread: Re: mail-in db/app
  • Index(es):
    • Date
    • Thread