On Sep 18, 2007, at 2:31 PM, Brian Moseley wrote:
the reason the web ui can't do the second part of that now is that it doesn't have any particular knowledge of any specific tickets. it can list all of the tickets on the item, and if there's only one read-only and/or one read-write ticket, it can just pick those. but what if there are more than one of each? which ones are the ones that chandler created when you published the collection originally? what if there are none? can the ui just pick two and use them? does it matter if those are the ones created by chandler or if they were created by some other application?
I wonder if it's so important to match up the tickets with the Chandler Desktop tickets. Most of the time I imagine Chandler users will only have 2 tickets anyway. In the cases where they don't, they will have created them manually through the Account Browser. I think we can just display all the tickets and let users figure out which ones they want to use. That's what we have to do in the Account Browser today.
we might be able to solve that problem by re-defining how we think of tickets. instead of allowing an arbitrary number of tickets to be issued for a collection, maybe we should only allow one of each type and have them automatically created when the collection is created. that way, assuming you're the person who published the collection, whenever you use desktop or web you can always ask the server to see the single read-only ticket for the collection and you can reliably construct a single sharing (/pim) url to give to others or to use yourself to subscribe in another desktop instance.
That would simplify things. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
