[Cosmo-dev] Bad ICS already extant

[Jared Rhine]

Randy's r3540 says:

* Perform additional validation on Calendar object by
validating serlialized Calendar can be parsed again. We
ran into a problem where bad .ics was allowed into db,
messing everything up. There is an inconsistency in
ical4j's validate() and parsing (validate() says its ok
but parsing barfs.) The idea is to never allow bad .ics
into the db.

What can we do about bad data already in the database?  This seems to 
affect the data migration process.  These ICS resources seem to have 
gotten into and out of 0.5 ok, as these real-world calendars have been 
in daily use, so something during 0.6 development got more restrictive?

(I'm a little concerned about interoperability, as there is bad ICS out 
there in the real-world, no doubt.  Now, there will be some resources 
that Cosmo can't store; instead an error will be returned, right?  Which 
error, btw; will there be a way to quantify the number of resources 
being rejected from say the logs?)

How does this interact with Chandler's behavior during publishing? 
Presumably Chandler allowed this data and submitted it during 
publication, and may do so again.  Will publication of collections 
containing such resources fail or just some events not succeed?

I'm certainly not saying the patch is bad or needs improvements; I'm 
strictly trying to understand the implications of this change on the 
current and future ecosystem.

-- Jared