From ben at bleything.net  Thu Feb 22 14:25:50 2007
From: ben at bleything.net (Ben Bleything)
Date: Thu, 22 Feb 2007 11:25:50 -0800
Subject: [Plist-devel] posted a few bugs today with patches
In-Reply-To: <85AC02DE-3C01-47D0-801E-878D2DB33DEE@mac.com>
References: <85AC02DE-3C01-47D0-801E-878D2DB33DEE@mac.com>
Message-ID: <20070222192550.GC5508@jeeves.bleything.net>

On Wed, Nov 29, 2006, Chuck Remes wrote:
> Is this thing on? <tap tap tap>

Believe it or not, the answer is yes.  Heh.  Patrick, you're cc'ed
because I'm not sure if you're on the list.  My apologies if you get
this twice.

> I sent an email to Ben earlier today with another patch for a bug I  
> ran across. He suggested I officially submit them to the rubyforge  
> bug tracker, so consider them submitted [1].

Thanks for doing so.  Please accept my sincere apologies for sitting on
them for so long.

> The first bug (and patches) were related to Plist blowing up if a  
> submitted plist had a null Date field in it. That makes the plist  
> invalid, but it shouldn't make Plist blow up either. I think it  
> should be tolerant of Garbage In hence the patch.

In the bug you say this:

  It should be noted that the Plist XML definition specifically disallows
  empty Date fields. However, we don't want our libraries choking on every
  malformed piece of data that it runs across.

I'm not sure I agree.  If the spec is explicit that nil date fields are
invalid, it's an exceptional case and should be dealt with as such.
That said, we should catch the DateTime exception and wrap it up in our
own that explains why it's a problem.

This actually leads to another discussion that I think Patrick and I had
in the past, about whether we should consider adding a strict/loose mode
for parsing.  In the strict mode, an exception would be raised there.
In the loose, you'd get an empty string back.  I think this is
ultimately the correct solution to the problem, since if it's only a
strict mode parser, you simply can't parse invalid plists.

Thoughts?

> The second problem was related to Rails sometimes putting submitted  
> forms (from the params object) into StringIOs. Passing this blindly  
> on to Plist for parsing blows up because Plist can only handle  
> Strings containing plists or Strings representing plist files on the  
> filesystem. The patch checks to see if the #file_name_or_xml object  
> respond_to?(:string) and pulls out the underlying String if it does.  
> Again, this makes Plist a bit more tolerant of weird things being  
> thrown at it.

I agree that the plist parser should be looser in what it accepts.  The
parser is Patrick's code so I want to get his opinion before I check
anything in.

> Ultimately that second patch should probably detect if an IO object  
> was passed in. If so, read from it to snag the plist hiding inside.  
> For now, this is a good stopgap.

I rewrote your patch.  StreamParser's initializer now makes every effort
to convert what was passed in to an XML string before continuing.  The
patch is down at the bottom of the message, and this is all copied into
the bug on RubyForge.  Your test still passes with this, and it has the
pleasant side effect of allowing anything that responds to #read to be
passed in.

How's that?  Patrick?

Ben

--

Index: lib/plist/parser.rb
===================================================================
--- lib/plist/parser.rb (revision 81)
+++ lib/plist/parser.rb (working copy)
@@ -59,8 +59,15 @@
   end
 
   class StreamParser
-    def initialize( filename_or_xml, listener )
-      @filename_or_xml = filename_or_xml
+    def initialize( plist_data_or_file, listener )
+      if plist_data_or_file.respond_to( :read )
+        @xml = plist_data_or_file.read
+      elsif File.exists? plist_data_or_file
+        @xml = File.read( plist_data_or_file )
+      else
+        @xml = plist_data_or_file
+      end
+
       @listener = listener
     end
 
@@ -78,15 +85,7 @@
 
       require 'strscan'
 
-      contents = (
-        if (File.exists? @filename_or_xml)
-          File.open(@filename_or_xml) {|f| f.read}
-        else
-          @filename_or_xml
-        end
-      )
-
-      @scanner = StringScanner.new( contents )
+      @scanner = StringScanner.new( @xml )
       until @scanner.eos?
         if @scanner.scan(COMMENT_START)
           @scanner.scan(COMMENT_END)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 155 bytes
Desc: Digital signature
Url : http://rubyforge.org/pipermail/plist-devel/attachments/20070222/9c4cc1cf/attachment.bin 

From cremes.devlist at mac.com  Fri Feb 23 09:43:23 2007
From: cremes.devlist at mac.com (Chuck Remes)
Date: Fri, 23 Feb 2007 08:43:23 -0600
Subject: [Plist-devel] posted a few bugs today with patches
In-Reply-To: <20070222192550.GC5508@jeeves.bleything.net>
References: <85AC02DE-3C01-47D0-801E-878D2DB33DEE@mac.com>
	<20070222192550.GC5508@jeeves.bleything.net>
Message-ID: <9D813B85-5E86-41A3-BB59-CFB789ACB8A5@mac.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Feb 22, 2007, at 1:25 PM, Ben Bleything wrote:

> On Wed, Nov 29, 2006, Chuck Remes wrote:
>> I sent an email to Ben earlier today with another patch for a bug I
>> ran across. He suggested I officially submit them to the rubyforge
>> bug tracker, so consider them submitted [1].
>
> Thanks for doing so.  Please accept my sincere apologies for  
> sitting on
> them for so long.

No problem. Everyone is busy!

>> The first bug (and patches) were related to Plist blowing up if a
>> submitted plist had a null Date field in it. That makes the plist
>> invalid, but it shouldn't make Plist blow up either. I think it
>> should be tolerant of Garbage In hence the patch.
>
> In the bug you say this:
>
>   It should be noted that the Plist XML definition specifically  
> disallows
>   empty Date fields. However, we don't want our libraries choking  
> on every
>   malformed piece of data that it runs across.
>
> I'm not sure I agree.  If the spec is explicit that nil date fields  
> are
> invalid, it's an exceptional case and should be dealt with as such.
> That said, we should catch the DateTime exception and wrap it up in  
> our
> own that explains why it's a problem.
>
> This actually leads to another discussion that I think Patrick and  
> I had
> in the past, about whether we should consider adding a strict/loose  
> mode
> for parsing.  In the strict mode, an exception would be raised there.
> In the loose, you'd get an empty string back.  I think this is
> ultimately the correct solution to the problem, since if it's only a
> strict mode parser, you simply can't parse invalid plists.
>
> Thoughts?

 From my standpoint, I just want the library to be able to parse  
through anything I throw at it. If you offered strict and loose  
parsing modes, I would always use the loose mode (even for output). I  
understand your desire for correctness though. With that being the  
case, a dual-mode approach sounds like a solid idea.

>> Ultimately that second patch should probably detect if an IO object
>> was passed in. If so, read from it to snag the plist hiding inside.
>> For now, this is a good stopgap.
>
> I rewrote your patch.  StreamParser's initializer now makes every  
> effort
> to convert what was passed in to an XML string before continuing.  The
> patch is down at the bottom of the message, and this is all copied  
> into
> the bug on RubyForge.  Your test still passes with this, and it has  
> the
> pleasant side effect of allowing anything that responds to #read to be
> passed in.

Ah yes, #respond_to(:read) is obviously a better way to solve this  
problem. I like it.

cr


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFF3v2TtEOEsNMQp04RAnr7AJ4pQ5qNmFjVbNIsbkdqX5Ej+Z7MYwCfbY2N
nNxCBdbxYrc6gqa8dzKqJRE=
=HJFf
-----END PGP SIGNATURE-----

From ben at bleything.net  Fri Feb 23 11:27:27 2007
From: ben at bleything.net (Ben Bleything)
Date: Fri, 23 Feb 2007 08:27:27 -0800
Subject: [Plist-devel] posted a few bugs today with patches
In-Reply-To: <A974A480-953B-4661-BDB0-EDF9DC4AAEF2@hexane.org>
References: <85AC02DE-3C01-47D0-801E-878D2DB33DEE@mac.com>
	<20070222192550.GC5508@jeeves.bleything.net>
	<A974A480-953B-4661-BDB0-EDF9DC4AAEF2@hexane.org>
Message-ID: <20070223162727.GA4735@jeeves.bleything.net>

On Fri, Feb 23, 2007, Patrick May wrote:
> My tendency is to stick to whatever Apple specs out.  When I started  
> writing plist, the spec was "Whatever the Property List Editor app  
> did."  I had trouble finding a spec online.  Could you send me the  
> url of the spec you are reading?

I agree (and I was just repeating Chuck, so he'll have to get you the
spec).

> Btw, I noticed that Apple has a binary format for plists.  Plus, Ben  
> will laugh at me when I note that Apple libraries handle indention  
> differently than the editor app -- they don't mangle multiline  
> strings.  These are things I am thinking about working on.

Yup, they do. plutil can freely convert between the two, and I'm told
that the system APIs that use plists can transparently cope with either
format, which is why I haven't bothered to explore the binary format
much.

That's interesting about indentation.  Personally, I don't care too much
about 100% matching what apple does, particularly in formatting, so long
as the structures we get when sucking the XML back in are identical.

> [ snippy snip ]
> Thanks for putting together this patch.  It sounds great.

No problem.  I'll check it in later today when I get to work and release
a new gem.  3.0.1, I think?

Ben

From ben at bleything.net  Fri Feb 23 11:28:45 2007
From: ben at bleything.net (Ben Bleything)
Date: Fri, 23 Feb 2007 08:28:45 -0800
Subject: [Plist-devel] posted a few bugs today with patches
In-Reply-To: <9D813B85-5E86-41A3-BB59-CFB789ACB8A5@mac.com>
References: <85AC02DE-3C01-47D0-801E-878D2DB33DEE@mac.com>
	<20070222192550.GC5508@jeeves.bleything.net>
	<9D813B85-5E86-41A3-BB59-CFB789ACB8A5@mac.com>
Message-ID: <20070223162845.GB4735@jeeves.bleything.net>

On Fri, Feb 23, 2007, Chuck Remes wrote:
> From my standpoint, I just want the library to be able to parse  
> through anything I throw at it. If you offered strict and loose  
> parsing modes, I would always use the loose mode (even for output). I  
> understand your desire for correctness though. With that being the  
> case, a dual-mode approach sounds like a solid idea.

Putting together a dual-mode parser is going to take some time.  I'll
poke at it and see what I can do, but I don't have a lot of time to work
on this right now.  No promises :)

Ben

From cremes.devlist at mac.com  Fri Feb 23 11:44:36 2007
From: cremes.devlist at mac.com (Chuck Remes)
Date: Fri, 23 Feb 2007 10:44:36 -0600
Subject: [Plist-devel] posted a few bugs today with patches
In-Reply-To: <20070223162845.GB4735@jeeves.bleything.net>
References: <85AC02DE-3C01-47D0-801E-878D2DB33DEE@mac.com>
	<20070222192550.GC5508@jeeves.bleything.net>
	<9D813B85-5E86-41A3-BB59-CFB789ACB8A5@mac.com>
	<20070223162845.GB4735@jeeves.bleything.net>
Message-ID: <45716916-42FA-47CA-B8B3-6D24C005B4E0@mac.com>


On Feb 23, 2007, at 10:28 AM, Ben Bleything wrote:

> On Fri, Feb 23, 2007, Chuck Remes wrote:
>> From my standpoint, I just want the library to be able to parse
>> through anything I throw at it. If you offered strict and loose
>> parsing modes, I would always use the loose mode (even for output). I
>> understand your desire for correctness though. With that being the
>> case, a dual-mode approach sounds like a solid idea.
>
> Putting together a dual-mode parser is going to take some time.  I'll
> poke at it and see what I can do, but I don't have a lot of time to  
> work
> on this right now.  No promises :)

That's okay. My locally patched copy does what I need it to do. <grin>

I'll have to dig up my reference to the plist spec. Since I did that  
research back in November, I swapped out that knowledge long ago.  
This might take me a bit.

cr


From ben at bleything.net  Fri Feb 23 23:55:18 2007
From: ben at bleything.net (Ben Bleything)
Date: Fri, 23 Feb 2007 20:55:18 -0800
Subject: [Plist-devel] posted a few bugs today with patches
In-Reply-To: <20070223162727.GA4735@jeeves.bleything.net>
References: <85AC02DE-3C01-47D0-801E-878D2DB33DEE@mac.com>
	<20070222192550.GC5508@jeeves.bleything.net>
	<A974A480-953B-4661-BDB0-EDF9DC4AAEF2@hexane.org>
	<20070223162727.GA4735@jeeves.bleything.net>
Message-ID: <20070224045518.GA16200@jeeves.bleything.net>

On Fri, Feb 23, 2007, Ben Bleything wrote:
> No problem.  I'll check it in later today when I get to work and release
> a new gem.  3.0.1, I think?

Checked in.  No new release yet, I'm going to explore strict/loose mode
parsing before I do that.

Ben