Re: more than one plist in a file.
Re: more than one plist in a file.
- Subject: Re: more than one plist in a file.
- From: Paul Thomas <email@hidden>
- Date: Thu, 1 Dec 2005 10:18:57 +0000
Hi Mr. Savant:
It looks like I might have to go that way eventually. It's not the
format of the file I'm interested in but I don't want to write the
code. Writing codecs like this is tedious and error prone. I'm sure
there is something in the Cocoa environment somewhere that can do
this for me - it's just a matter of finding it.
Cheers,
Paul.
On 30 Nov 2005, at 20:12, I. Savant wrote:
Paul:
I'm sure you have your reasons for writing it in pseudo-xml, but
would you consider a much simpler format? More like a standard log
file:
DATE STRING
DATE STRING
Each line is a 'record', separated by tabs (or some other
character). This can easily be appended and later decoded (and is
more easily human-readable). This of course assumes newlines will
never be in your strings ... even so, you could encode newline
characters and decode them when reading the file back in.
--
I.S.
On Nov 30, 2005, at 2:56 PM, Paul Thomas wrote:
Hi list,
I have an application that is logging events (date + string +
attributed string) to a file and I want to be able to read in the
file when I restart the app. I can't use a straight forward plist
(array of dictionary of {date,string,data}) because the files can
get large and I don't want to rewrite the entire file to append a
single event. So I am using a NSFileHandle to append the data and
I don't want to have to write my own encoding/decoding routines.
Is there anyway to reuse the plist architecture for this?
Writing a plist for every event using NSPropertyListSerialization
only half works because I can't find the start of the next plist
when it comes to reading the file back in. Plus it bloats the file
somewhat.
Ideally, I'd like my log file to look like
...
<date>blah blah</date>
<string>bork bork</string>
...
and so on without the greater structure.
My only alternative seems to be to use the scanner.
Maybe I'm completely missing the point though?
Thanks,
Paul.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40gmail.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden