On 3/16/07, Mimi Yin <[EMAIL PROTECTED]> wrote:
Suggestion:+ In the future, we could re-design the grant a ticket functionality so that the table for tickets doesn't appear until you 'grant a ticket.'
sounds fine to me. also, feel free to come up with different terminology for granting and revoking tickets. i used those words because that's how the webdav ticket spec is writtne.
Suggestion: + In the near-term, could we label the column DAV Type? and rename the Name column: Collection Name.
the dav type column will need to communicate that a collection can act as not only a dav collection (all collections can do this) but possibly also as a caldav calendar collection and/or as a carddav addressbook collection.
+ In the near-term, we can also make sure we distinguish between Collections versus Items. + In the future, we can consider adding a column to display the kind of each item: Note, Message, Task, Event, etc. bcm, what's the use case for this? What is the Admin or Chandler Server user doing when inspecting this kind of information?
mainly getting a general overview of the contents of the collection and making sure that all of the data looks as expected. the account browser is meant to comprehensively show all of the information we have about an item or collection. this is especially important on the detail page for the item or collection, but i think it's handy to see the stamps on each member of a collection when you're looking at the list of members on the collection detail page.
Proposal is: [Chandler] [DAV] [Feeds] Logged as: https://bugzilla.osafoundation.org/show_bug.cgi?id=8060
either we need to also add [Browser] or we need to somehow educate the user that the chandler url can also be given to other people to be plugged directly into a browser.
I'm assuming here that [Chandler] would cover both Chandler Desktop and Chandler Hub. I don't think we need to have separate links for each one?
also i think it would be wrong to give a hub link to people who are running their own cosmo instances.
1. What are the reasons for *not*making the ticket-URLs in the Collection Details Dialog? When would you want to hand out non-ticket URLs versus the ticket URLs?
if you're looking at a collection that you created yourself, then you by definition don't have a ticket to put in the url, cos you can access the collection just by virtue of being logged in to cosmo. if, for instance, you wanted to subscribe to the feed for your own calendar, you could either 1) plug the ticket-less feed url into your feed reader, which would then ask for your cosmo username and password, or 2) grant a ticket on your calendar, then plug its ticket-bearing url into your feed reader, which would not ask for your cosmo username and password. the advantage of option 1 is that the server knows specifically who you are, not just that you are some anonymous being presenting a ticket, and so it can tailor what it sends specifically to you, based on your preferences, past activity, etc.
Suggestions: What if users only gave out ticket-URLs? Then, if the user is already: + Logged into their Chandler Hub / Chandler Server account; and + Subscribed to the collection in question; then + We just log them in; otherwise + We send them to a 'ticket-view' of the collection.
that's fine for the web ui, but it doesn't work for feed readers and other external applications which don't send cookies that identify your server session and remember-me state. ticket urls are for sharing your stuff with other people who access the server anonymously. non-ticket urls are for accessing your own stuff and letting the server know your specific identity.
Also, for Preview, won't users have access to the ticket-[Chandler] URLs from the Collection Details Dialog because Chandler Desktop will have switched over to the new sharing format?
only for collections they have subscribed to with tickets, not for collections they have created or shared themselves.
Additional suggestion from bcm: Make 'home collection' page look different from sub-pages. I think this will require some up-front design work and will be hard to do in a vacuum (without touching other page templates, etc). I would recommend punting this to future, Priss?
you don't think there's anything minimal that can be done? _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
