[Cosmo-dev] Bad ICS already extant

[Jared Rhine]

Thanks for the various commentary about this issue.

 >> What can we do about bad data already in the database?

This core issue, "bad data already in the database" seems still open and 
problematic for migration.

Randy Letness wrote:
> I added the additional parse 
> check to prevent this, but it shouldn't effect 0.5 data as that data has 
> already run through parse().

I think 0.5 data is affected in the sense that these broken resources 
can't be retrieved from a 0.6 instance.  It seems like most dogfooder 
collections in Cosmo have broken resources, as so to-date, we haven't 
seen anyone be able to restore a collection from a migrated instance.

>> How does this interact with Chandler's behavior during publishing? 

> It depends, if you are talking about the old Chandler publish than if 
> Chandler submits bad .ics then it will fail.

This will seem a regression, in that users were able to put and get the 
same resources under 0.5, but seems manageable.  Like Bobby says, we'll 
get bug reports, investigate, and see about making Cosmo accept those 
particular resources.  So it seems the primary issue is about existing 
collections breaking if we update osaf.us to Cosmo 0.6.

 > If you are talking about
> morse code, then this doesn't apply because there is no .ics being 
> transmitted.

Ok, I'll have to think a little bit about this aspect.  It's unlikely to 
affect a 0.6 migration (within the next couple weeks), as morse code 
won't be in play.

-- Jared