So I mucked around with this a bit. I agree there is a bit of
weirdness with the free busy stuff. Personally I install new versions
of Chandler all the time and it's very convenient to be able to
restore the shares so I don't have to create and give out a new
ticket to everyone. I kind of think of free-busy the same way. I will
have published this, sent the ticket to many people who are
subscribed and just because I wipe out my repository, I don't want to
have to do this again. I just hook up my existing shares and
continue. I should be able to somehow reconnect up with my free busy
as well.
So basically, right now when the ifb is created, it uses the My
Calendar collection for updates. There is a dependency between the
free-busy data and the My Calendar data. If I delete my repository
and start over, I really don't want to restore the old free-busy
data, I want it to use whatever is in the My Calendar collection. I
could have imported all the data into My Calendar to be the same as
before I deleted the repository but, I may not. In this case, I
really want the ifb to recalculate itself based on the new data in My
Calendar and it isn't quite the same as restoring an old share. Maybe
if the user tries to publish free-busy again, they are prompted with
a dialog asking if they want to update the ifb that the currently
have (not sure if we can even do this). There could also be a
checkbox in the restore dialog but I agree with Philippe, it's funny
to have it in the list of shares and it doesn't quite work the way we
want.
There is also this weird situation where I publish the My Calendar
collection and I publish my free-busy. Sorry this isn't a good use
case but let's say Katie is looking at both my free-busy and has read
write access to my calendar. If I delete Chandler, can she continue
to update my free-busy when she makes to my calendar? I would say
yes. In reality Katie might not have both the free-busy share and
access to my calendar directly but she could edit my calendar that
will update the free-busy share others are subscribed to. If I
reinstall Chandler, what happens when I restore my free-busy? I may
have restored the My Calendar share first, in which case, I just kind
of reconnect to what everyone else is doing. If I restore my free-
busy but change the My Calendar collection what happens? Would the
free-busy be recalculated so everyone subscribing to the original
URL, would just get the update when they synched?
The above paragraph kind of addresses the question of what if I don't
reconnect/restore my free-busy. It may continue to have a life of
it's own. I like the idea of being able to remove it. I thought we
had that logged as an enhancement already, if not I will add it to
the dogfood list.
Sheila
On Apr 12, 2006, at 12:54 PM, Philippe Bossut wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
