[Design] Restore and Free/Busy

[Philippe Bossut]

Hi,

I'm bringing this here because we're starting to have a "design 
discussion in Bugzilla" and we better have that one here.

The bug is: http://bugzilla.osafoundation.org/show_bug.cgi?id=5639

The issue is about showing or not showing the .ifb (free/busy) share in 
the Restore dialog: when using this dialog after restarting Chandler on 
a clean repository (something you still need to do on a regular basis 
because of the absence of schema evolution), you can now see the 
free/busy share in there.

I was thinking that it shouldn't be there at all, my rationale being 
that if the user published the free/busy, the user should simply be 
considered a "free/busy" publisher kind and act as if this info has just 
been published by said user.

Jeffrey is pointing though that the free/busy is a share like any other 
share and that, apart from its display, it's not different from a 
collection.

I think I understand Jeffrey's point however, I wonder:
- what "restoring" free/busy should do? Right now, it creates a 
collection with empty events which is plain wrong, that's not what the 
publisher of the free/busy share wants. What he wants is to have 
Chandler in a state that was identical to what it was before he has to 
clean up his repository, i.e., the .ifb over there and recognized by 
Chandler (so that Sync works).
- what "not restoring" free/busy means? Now if I choose not to restore 
the ifb, what is this ifb supposed to be? Can others still subscribe to 
it? what does it mean to do that? As a user, what I'd like to do if I'm 
not restoring something is to delete it so that no one takes those info 
into account anymore. Having an option to delete a share right here and 
there in the Restore dialog would be extremely useful (for Cosmo folks, 
I know you can do that through the Cosmo web UI but I'm talking about 
doing this from Chandler)

Thoughts?

- Philippe