[Chandler-dev] Re: [chandler-users] Re: Using Chandler
Mimi Yin
mimi at osafoundation.org
Mon Feb 4 09:11:44 PST 2008
Hi Sam,
Since our conversation is getting pretty deep into design issues, I'm
forwarding this thread over the to the Chandler-Development list. If
you haven't subscribed to this list, I encourage you to subscribe.
You will get a much better feel for what we're working on. It's also
the best forum for figuring out how you can contribute to the project.
I will let one of the developers answer your technical questions, but
I can speak to some of the design issues in-line:
On Feb 2, 2008, at 8:05 AM, Sam Halliday wrote:
> 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
Thanks for logging this issue.
> 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.
Could you provide some more details about the group you're trying to
set up Chandler for? Is it a pretty consistent team of the same
people? Clients that change every few months? Mixture of both?
>
> 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.
I'd like to better understand why email is problematic for your
group. Security? Too many notifications? Anyone who is sharing with
Chandler will only ever see 1 version of the event-invitation, even
if they receive it via Email + Sharing. Chandler is smart enough to
reconcile the 2 to be the same item.
> 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.
You can accomplish this workflow in the Desktop application today
with the caveat that the Chandler item will be attached in the email
as an .eimml file along with an .ics file that Outlook / iCal can
understand. Again, I'd like to better understand your email
requirements.
Best,
Mimi
>
> 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
More information about the chandler-dev
mailing list