[chandler-users] Re: Using Chandler

[Sam Halliday]

Hi Mimi,

(mailing list users may have missed Mimi's reply... which is quoted  
below).

Re: Chandler Desktop, I've now filed a bug against the OS X breakage at

   https://bugzilla.osafoundation.org/show_bug.cgi?id=11810

Can I ask why the Desktop client is written in Python, when the server  
is all Java? Surely there must be a lot of code duplication because of  
this decision (also... 90MB uncompressed!?!). This means I can't help  
out with client-side hacking unfortunately. How well documented is the  
protocol that the client uses to communicate with the server? Is it  
XML based? I'd love to write a mini J2ME client (which would have  
seriously benefited from existing J2SE desktop client libraries).

It's great to hear you're all thinking along the lines with regard to  
collaboration and sharing of events/tasks! I'm excited to see what you  
come up with... my primary interface will continue to be the web  
interface though.

I'm especially interested to see how communication between users is  
achieved. I would absolutely not like to use e-mail for passing  
messages around to other chandler users on the same server, preferring  
this to be contained within the Chandler protocol itself. However, I  
would like to be able to send e-mail notifications of events to people  
who aren't using Chandler. A typical use case would be:-

- I want to set up a meeting with a client, we've arranged a date/time  
by e-mail/phone
- I want to invite another member of our team to attend entirely in  
the web interface (or desktop client)... so I send out more than one  
invite to see who would like to join me. I await their responses.
- When all details are arranged internally, I want to be able to e- 
mail a Chandler-independent confirmation to the client with the event  
information, address information (i.e. physical details and  
directions) and an attached .ics/outlook file if they use it.

On 2 Feb 2008, at 02:22, Mimi Yin wrote:
> The Desktop and Web application are designed to work together, so  
> the members of your team can choose what they'd like to use  
> depending on what their individual needs are.
>
> Desktop users aren't constrained to using the Desktop. So long as  
> you publish all of your data to the server, you will be able to  
> access it from the web app whenever you need to.
>
> I think I wasn't clear about Chandler's email functionality either,  
> so please see more in-line below.
>
> On Feb 1, 2008, at 4:06 PM, Sam Halliday wrote:
>> I did actually try out the desktop client on OS X Leopard, but it  
>> timed out when attempting to connect to the server. It seemed to  
>> pick up on the SSL certificate ok, but after that it was just a  
>> whole lot of waiting. Regardless, the web interface is much more  
>> important for us because it is accessible anywhere and there is  
>> much more chance of getting everybody to use it!
>
> That's not good. Have you had a chance to log this as a bug? This is  
> definitely something we should be looking into.
>
>>
>> To be honest, I am not at all interested in handing over my e-mail  
>> handling to Chandler... I have years of e-mails archived in Mail  
>> and I love it to pieces. I see e-mail and project management as two  
>> completely separate tools. Although they work together, I don't  
>> feel one needs to embed the other. For example... the convenient  
>> mailto links in the web interface are very handy (they'd be even  
>> handier if they embedded links in them to shared collections/ 
>> events!), but I wouldn't want anything more than this.
>
> Yes! We agree. Chandler Desktop isn't meant to handle all of your  
> email. Email functionality is only present as a way to get data in  
> and out of Chandler. We are in the process of paring down the user  
> interface so that people aren't misled into thinking it's mean to be  
> an email client.
>
>>
>> Although the desktop client is capable of sending events and tasks  
>> to other users as e-mails... this is not quite what I mean (the web  
>> interface can also do this). I would like the ability to create an  
>> event, which I can send on to people for inclusion in their  
>> calendar (granted, e-mail could be a possible medium to do this).  
>> If I update the event, their (read-only) event (which is actually  
>> in their calendar, *not* in one of their subscriptions) gets  
>> updated as well. I do not believe the Chandler server (not the web  
>> app) even supports such a setup... and it's this support that I am  
>> requesting.
>
> Chandler Desktop supports pretty much what you're describing. You  
> can email event and task items around and they will render in other  
> Chandler Desktop clients as events and tasks. Everyone also receives  
> the contents of the emailed item in plain text as an email. If the  
> item you're emailing around is an event, the email will also include  
> an .ics event that they can drag into their particular calendar  
> application.
>
> From Chandler Desktop, you can continue to edit items you have  
> already sent/received and send them again as an Update. (The main  
> difference between what you're describing and what I'm describing is  
> that any Chandler Desktop user can update items received via email,  
> not just the original sender.)
>
> All recipients will receive the Update as email. Chandler Desktop  
> recipients will receive the Update as an update to the original  
> item. In other words, Chandler Desktop users won't end up with  
> multiple copies of the same item when updates are sent. Instead, the  
> updated item will overwrite the original item.
>
> Does that make sense?
>
>> Perhaps related, I believe the web interface could benefit from a  
>> message passing system between registered users... but not e-mail.  
>> More like a notice board of incoming actions, where the kinds of  
>> actions you can send out are limited to things like:-
>>
>> - create an invitation for a user to subscribe to my calendar
>> - invite a user to attend my event
>> - assign a task to a user
>> - accept or reject an invitation (calendars, events or tasks... the  
>> response the above 3 actions)
>
> Yes, we've been thinking along the same lines as well. We've talked  
> about even more granular notifications for things like:
>
> + Editing the Notes field of an item: Who edited it and what did  
> they do.
> + Deleting items
> + Creating items
> + Changing event date/times
> + Changing triage status, etc.
>
>> I'm actually able to hack on Java, so I'd be interested in learning  
>> more about the guts of Chandler. I'm not so up on my Spring/JSP so  
>> I might give the web app work a miss... but I'd love to perhaps  
>> work on a J2ME or twitter-based client (well, a twitter bot that  
>> can speak to Cosmo). Although, if there is any engine work that you  
>> need a hand with, please let me know. I have Hibernate/JPA/Tomcat  
>> experience.
>
> That's great to hear! I will let one of the developers respond to  
> you about how you might be able to help.
>
> Best,
>
> Mimi
>
>>
>> On 1 Feb 2008, at 22:53, Mimi Yin wrote:
>>> Thanks for writing in with all this great feedback. I understand  
>>> you've set up your own server. I wonder if you've considered  
>>> downloading and using the Desktop client against the server  
>>> instead of the web UI.
>>>
>>> http://chandlerproject.org/Projects/DownloadChandlerDesktop
>>>
>>> It sounds like you're looking to work quite a bit in the app and  
>>> the Desktop client provides a more robust user experience right  
>>> now. For example, most of the things you've requested below are  
>>> already supported in the Desktop.
>>>
>>> + Locale detection with appropriate date formats
>>> + Auto-save
>>> + Ability to share
>>> + Assigning tasks to others (via email)
>>> + Sending events to others (via email)
>>> + Re-ordering collections (it's been implemented but isn't yet  
>>> available in an end-user release)
>>> + Better parsing for dates and times
>>> + Server time-out issues
>>>
>>> Here's the bug for reordering collections. When Grant checks in  
>>> the patch, feel free to apply it and try it out.
>>> https://bugzilla.osafoundation.org/show_bug.cgi?id=5058