[chandler-users] Re: Using Chandler

Mon Feb 4 17:42:35 PST 2008

Hi Sam
>
>
> 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.

A good historical take on this question can be found here:

http://bcm.maz.org/2008/01/always-nice-to-wake-up-to-a-ba.html

In short: it made sense at the time the server project began, and  
changing course at this point would basically be starting a new  
project :-)

> 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).

Pretty well, actually, and (at the moment) fairly up to date:

The web ui uses our Atompub service, a RESTful, "document oriented"  
protocol:
http://chandlerproject.org/Projects/CosmoFeedServiceSpec

The desktop client uses a custom protocol that is much "sync  
oriented," Morse Code:
http://chandlerproject.org/Projects/CosmoMorseCode

In general, most of the information you'd want to get started on a  
project like the one you describe can be found here:
http://chandlerproject.org/Developers/WebHome

Please feel free to drop into #cosmo on irc.freenode.net or send mail  
to cosmo-dev at osafoundation.org with any dev related questions you have!

>
>
> 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.

Thanks for the input! It sounds like most of what you want is doable  
or almost doable in the current web ui, certainly the "setup" and  
"email" portions are at least partially supported, and probably would  
not take much more work to polish. We're definitely exploring ways of  
facilitating calendar sharing via the web at the moment, and what you  
want is easily done via the Desktop client through the email  
functionality we currently support.

-Travis

>
>
> 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
>
> _______________________________________________
> chandler-users mailing list
> chandler-users at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/chandler-users