Links

• A blog post on complexity by an author of JXTA.
• A mildy interesting thread on import/export/synch of calendar data

Notes from talking to Brian Skinner

Brian & I were talking on a tangent about how exactly one Chandler user would get the message "I have stuff to share with you" to another Chandler user. Ideally the Chandler software would handle both the message and the reaction, that is the sharing invitation would be automatically generated at the user's request, and then automatically handled at the recipient's end by synchronizing to the newly shared data at the recipient's request. The recipient shouldn't have to cut and paste URLs although the recipient might click on a URL or button to approve the sharing invitation. Whatever the design goals are, however, what we can actually achieve here is limited by technology available. These were the options I could think of.

Sharing invitation via email

• Send an email with an HTTP address that launches a plain HTML view of the shared data.

  *Advantage

  easy to implement; very interoperable.

  • Disadvantage: doesn't launch Chandler; not very usable, doesn't support shared authoring well.
• Send email with a "chandler:" scheme URL which launches Chandler when clicked
  • Disadvantage: to get this to work, we would have to register the Chandler application with the local OS on install so that it gets launched when a "chandler:" URL is clicked. More research would be needed to see how feasible this really is on various OS's.
  • Advantage: relatively usable.
• Send email with magic text in it which, when that email is scanned by Chandler during its normal email-downloading activity, causes Chandler to go find the shared data.
  • Advantage: Easy to implement.
  • Disadvantage: doesn't allow user to have a primary mail client other than Chandler. Possible workaround: could configure Chandler specifically to scan IMAP/POP stores just to find these emails and ignore all others.
  • Variation: could put the magic text in a header rather than in body.
• Send email with code that gets executed at recipient.
  • Disadvantage: May not be technically feasible. People are understandably leery about allowing email to contain runnable code. Yet, zapplets work to a certain extent.
• Send email with HTTP URL that goes to a Web site, and the Web site runs code which launches Chandler to look at correct item.
  • Advantage: launches Chandler no matter what email client is used; HTTP URL and Web page could have additional helpful text. This sharing intermediary server could be trusted by users and that's why they allow the code to run.
  • Disadvantage: might require us to run the server.
  • Variations: the server could actually be the other Chandler sharing machine; however this is harder to know whether to trust. (Or it could be your own Chandler instance if you could depend on Chandler to always be running: http://127.0.0.1:13383/shareimport?data=foo-bar-baz -- KragenSitaker - 23 Apr 2004)
    • Using the HTTP scheme on a predictable port to talk to the local instance of Chandler seems to me to be the optimal path to take for emails that need to talk to Chandler. Chandler would have to be running for this to work from non-Chandler email clients, perhaps it would be desirable to give users the option of keeping a lightweight "Chandler service" running at all times that would listen for requests on that port, if the service process got a request that needed user interaction it could spawn a GUI process. -- JeffreyHarris - 26 Apr 2004

Non-email sharing invitations

• Send an XMPP message directly to the Chandler process on the other machine -- special feature of XMPP address structure.
  • Disadvantage: User must have XMPP account, Chandler must be running (currently XMPP addresses don't dynamically launch applications). Could do more investigation to see if XMPP experts know other options.
• Use Chandler-to-chandler direct protocol of any kind.
  • Advantage: no email ugliness.
  • Disadvantage: both chandlers must be running; must know machine addresses and solve firewall problems.

Recommendations on group task management

mail from Yair

At Omniva, we had a pretty good system that could do the MS Project like things, but allowed individuals to update there own status and generated web reports automatically. I forget the name of this.

We also used Twiki for brainstorming on task lists and Bugzilla for Qa/customer bugs.

The group on currently working with is using Outlook and a seperate Bug DB. Basically, they created a public folder in Exchange that contains tasks, and everyone in the group can add or update the task list. The bug DB contains customer and QA bugs and the task list contains features/developement tasks. There's an "owner" field that says who is responsible for finishing that task. The whole thing is public, and it seems to work ok because you can attach arbitrary documents and/or urls into the details of the task list. There are priority (low/normal/important), category, and a "% complete" fields for sorting/tracking. Also, you can create a set of "public views" for common sorting/grouping/filtering, so you can have a view that displays "high priority tasks by category and owner".

mail from Stuart

The tool used at Omniva is called Enact. We bought it right before Netmosphere was acquired by Critical Path. We use Version 4.2. CP closed down the product and the founders bought it back and are in business again. They are up to version 5.3 (see http://www.enact.cc/index.htm). We still use the product for basic schedule management. We use Twiki for our technical intranet and Bugzilla for bug tracking. We have started using www.salesforce.com for support issues.

-- LisaDusseault - 23 Apr 2004