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
[EMAIL PROTECTED]
http://lists.osafoundation.org/mailman/listinfo/chandler-users
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
