On Mar 19, 2013, at 1:19 , Jens Alfke j...@mooseyard.com wrote:
On Mar 18, 2013, at 5:14 PM, Rick Mann rm...@latencyzero.com wrote:
NSArchiver calls look like -setValue:forKey:, so it seems reasonable that
the protocol could be usurped to write out fairly clean user defaults plists.
On 19 Mar 2013, at 10:02, Marcel Weiher marcel.wei...@gmail.com wrote:
On Mar 19, 2013, at 1:19 , Jens Alfke j...@mooseyard.com wrote:
On Mar 18, 2013, at 5:14 PM, Rick Mann rm...@latencyzero.com wrote:
NSArchiver calls look like -setValue:forKey:, so it seems reasonable that
the
On 19/03/2013, at 10:07 AM, Rick Mann rm...@latencyzero.com wrote:
I'm a little bit surprised that I can't add my NSCoding-conforming object
directly to NSUserDefaults. Why is this? Is it just a long-standing oversight
of NSUserDefaults, or is there a technical reason why it doesn't work?
On Mon, Mar 18, 2013, at 04:07 PM, Rick Mann wrote:
I'm a little bit surprised that I can't add my NSCoding-conforming object
directly to NSUserDefaults. Why is this? Is it just a long-standing
oversight of NSUserDefaults, or is there a technical reason why it
doesn't work?
A couple possible
On 19/03/2013, at 10:21 AM, Rick Mann rm...@latencyzero.com wrote:
t seems like an NSArchiver subclass could call -encodeWithCoder: to create a
dictionary that could live in a plist file (as opposed to creating an
NSData), and it could easily be used transparently. The advantage to this is
On Mar 18, 2013, at 4:21 PM, Rick Mann rm...@latencyzero.com wrote:
It seems like an NSArchiver subclass could call -encodeWithCoder: to create a
dictionary that could live in a plist file (as opposed to creating an
NSData), and it could easily be used transparently. The advantage to this
On Mar 18, 2013, at 16:46 , Jens Alfke j...@mooseyard.com wrote:
It wouldn’t be human-readable. NSArchiver doesn’t produce readable output.
Even if you made a version whose output was a tree of directories, it would
still be pretty unreadable due to all the metadata in it. (After all, XML
On Mar 18, 2013, at 16:30 , Kyle Sluder k...@ksluder.com wrote:
2. NSCoding is not trustworthy. Your app must blindly trust any object
archive it loads. This is a significant security risk.
I don't think that argument is any more true for what I'm proposing than what
what exists today.
--
On Mar 18, 2013, at 5:14 PM, Rick Mann rm...@latencyzero.com wrote:
NSArchiver calls look like -setValue:forKey:, so it seems reasonable that the
protocol could be usurped to write out fairly clean user defaults plists.
There’s a lot of other gunk the archiver needs to store so it can handle
On Mar 18, 2013, at 5:15 PM, Rick Mann rm...@latencyzero.com wrote:
2. NSCoding is not trustworthy. Your app must blindly trust any object
archive it loads. This is a significant security risk.
I don't think that argument is any more true for what I'm proposing than what
what exists
On Mon, Mar 18, 2013, at 05:15 PM, Rick Mann wrote:
On Mar 18, 2013, at 16:30 , Kyle Sluder k...@ksluder.com wrote:
2. NSCoding is not trustworthy. Your app must blindly trust any object
archive it loads. This is a significant security risk.
I don't think that argument is any more true
11 matches
Mail list logo
