headers
Andre Mueninghoff | 1 Mar 2007 01:09

Re: Re: [Chandler-dev] Re: [chandler-users] osaf.us updated to Cosmo 0.6.0

Hi, FWIW, none of the nine collections in question were exports from
Outlook. All events were entered in either Chandler or Cosmo, and by
hand in ics files. For some bug research quests, I would examine ics
files, occasionally hand-editing them to remove recurrence info. I never
saw either the CATEGORIES or RESOURCES fields in the ics files. I did
have an issue with an event in the Andre_Cal and ExtFamily_Cal
collections at the time of my first restore from Cosmo 0.6. I had DND'd
a yearly event from ExtFamily_Cal to Andre_Cal, and then stamped the
first instance in Andre_Cal as a task. However, I was never able to see
the task in any of task views. I synched with Cosmo 0.5, and then found
I could not restore. (I have no record of the error.) Suspecting the
phantom task, I deleted the event from both collections in Cosmo. These
collections were then migrated to Cosmo 0.6. Also, the name of the
yearly event included an apostrophe. 

Please let me know if you have any questions. 

Thanks, Andre

On Wed, 28 Feb 2007 12:41:53 -0800, "Jeffrey Harris"
<jeffrey <at> osafoundation.org> said:
> Ted Leung wrote:
> > Do we have an idea of how many users are affected by this bug?   Do we
> > need to do a patch against 0.6.0?
> 
> The weird data was caused by the Chandler bug 8240, which will hit:
> 
> 1. Chandler trunk users (not alpha4 users) who
> 2. Have CATEGORIES or RESOURCES fields in imported icalendar data with
> multiple values set.  I think this will mostly be people who've brought
(Continue reading)

Permalink | Reply | 7 comments |
headers
Andre Mueninghoff | 1 Mar 2007 01:31

Re: Cosmo Home Collection Browser

Hi Brian, On Cosmo 0.5, I have used the HTML view frequently, I would
say approx 80% of the time that I used the account browser for
something. This may have been driven by how the 0.5 account browser
screens were laid out, for example, being unable to remove an event from
the event detail page. I need some time with 0.6 to give a better
answer. 
Thanks for asking.
Andre

On Wed, 28 Feb 2007 08:28:16 -0800, "Brian Moseley"
<bcm <at> osafoundation.org> said:
> On 2/28/07, Andre Mueninghoff <andre_mueninghoff <at> fastmail.fm> wrote:
> 
> > Some more feedback: The enhancements to the account browser are
> > terrific, for example, the richer information set about events and such.
> > Thanks much!
> 
> glad to hear it. the account browser is mostly a diagnostic tool with
> a raw interface. i hope that for preview, or shortly thereafter, we'll
> be doing an extensive redesign to 1) ajaxify it, 2) add better
> navigation, and 3) reorganize the information to be more consistent
> and make more sense. if you have any specific suggestions, we'd love
> to hear them.
> 
> one question: do you use the "view as html" option for calendars and
> events? i've been considering removing those now that we have the
> calendar ui in place. i think it's important to retain a way to see
> the raw icalendar behind an event and would retain that, but i don't
> see much need to have separate pages showing summary, start date, etc
> in the account browser.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ted Leung | 1 Mar 2007 01:31
Favicon

Cosmo Engineering Meeting, Mar 1, 2pm PST

We'll be doing a postmortem of Cosmo 0.6.  If you have advance  
thoughts, please put them in <http://wiki.osafoundation.org/Journal/ 
CosmoMeeting20070227>.

We'll be on my phone bridge.

Ted
Permalink | Reply | 0 comments |
headers
Ted Leung | 1 Mar 2007 01:56
Favicon

Cosmo landing page typos

Hi folks,

I'd like to start a precedent for doing as much work on Cosmo landing  
pages, etc on the cosmo-dev list.   To that end, I want to report a  
few typos on the main page:

* The 0.6 release is Cosmo project's first experimentally usable web  
calendar application. => Cosmo 0.6 is the first release to include an  
experimentally useable web calendar application.

* The Cosmo project encompasses both a sharing server as well as web  
application pieces of the Chandler small workgroup collaboration  
suite. => Cosmo includes both a sharing server and web application  
pieces of the Chandler small workgroup collaboration suite.

* Cosmo supports both one-way sharing and multi-way sharing with many  
people editing the same shared calendar collection. => Cosmo supports  
both one-way sharing and multi-way sharing of calendar collections.

Ted
Permalink | Reply | 0 comments |
headers
Morgen Sagen | 1 Mar 2007 02:24
Favicon

Re: cosmo 0.6.1 EIMML changes


On Feb 26, 2007, at 6:47 AM, Randy Letness wrote:

> I've checked in changes into the 0.6.1 branch to support items in  
> multiple collections and note modifications.  The next step is to  
> make morse code take advantage of the changes.
>
> Recurring event exceptions are now represented as separate  
> NoteItem's, that contain a reference to a master NoteItem.  This  
> means a recurring event exceptions is now stored as a separate item  
> in Cosmo, just like in Chandler.  It seems like we need to add a  
> parentUuid field to the note record type in EIMML.  If present, the  
> value of "parentUuid" is the uuid of the master note.
>
> So for an event exception, the following records would be emitted:
>
> item
> note (with parentUuid set)
> eventModification
>
> Does this make sense?
>
> -Randy
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev <at> lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev

Sorry, I was away last week, and am still catching up.
(Continue reading)

Permalink | Reply | 21 comments |
headers
Brian Moseley | 1 Mar 2007 02:57
Favicon

Re: cosmo 0.6.1 EIMML changes

On 2/28/07, Morgen Sagen <morgen <at> osafoundation.org> wrote:

> So, I looked back at our conversation on Jan 9 and I don't think we
> discussed emitting an item or note record for modifications.  Or if
> we did, I missed that part.  This issue is probably worth
> revisiting.  I think what Jeffrey has implemented only emits
> eventModification records (and not additional item and note
> records).  Randy, can you elaborate on the changes you made?

there was definitely a conversation about this. it might have been
f2f, maybe during the week everybody was in town. i don't remember
everybody that was in the room. we were told at that time that item
and note attributes, like reminderTime, could change for
modifications, and therefore we needed item and note records for them.
iirc, it was said that a modification didn't have to be stamped as an
event at all.

> The other two issues to follow up on are:
>
> 1)  triageStatus, triageStatusChanged, plus a new attribute, auto-
> triage-state, and how those are getting rolled into a single EIM
> field, as discussed here:
> http://lists.osafoundation.org/pipermail/cosmo-dev/2007-February/
> 002881.html
> http://lists.osafoundation.org/pipermail/cosmo-dev/2007-February/
> 002954.html
>
> 2)  lastModifiedBy, as discussed here:  http://
> lists.osafoundation.org/pipermail/cosmo-dev/2007-February/002920.html
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Moseley | 1 Mar 2007 03:06
Favicon

"add to my calendars" feedback

today i used the "add to my calendars" feature for the first time,
subscribing to ted's calendar on osaf.us. it was very satisfying :D

one thing that can improve this workflow is allowing me to specify a
name for the subscription when i click the "+" icon to add the
calendar. the name of ted's calendar is "Work", and so that is the
name of my subscription to his calendar. i was able to use the
collection details dialog to change the name of the subscription to
"Ted Leung", which was nice, but it would be even better if i could do
this when adding the calendar in the first place.

this also really makes me want overlay. when i need to schedule a
meeting with ted, i really want to be able to look at his calendar
overlaid onto mine rather than having to flip back and forth between
the two. alternatively, what might be useful is some sort of
scheduling page where i could select ted and have the page show me all
the blocks of time that we both have free.

anyway, great work by matt, travis and bobby on this feature!
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
Permalink | Reply | 0 comments |
headers
Randy Letness | 1 Mar 2007 06:20
Favicon

Re: cosmo 0.6.1 EIMML changes

Morgen Sagen wrote:
>
> Sorry, I was away last week, and am still catching up.
>
> So, I looked back at our conversation on Jan 9 and I don't think we 
> discussed emitting an item or note record for modifications.  Or if we 
> did, I missed that part.  This issue is probably worth revisiting.  I 
> think what Jeffrey has implemented only emits eventModification 
> records (and not additional item and note records).  Randy, can you 
> elaborate on the changes you made?
>

In Cosmo 0.6,  the master event and all exceptions are stored in a 
single event stamped item.  We decided to change this in 0.6.1 to be 
more like Chandler's model, where an event exception is modeled as a 
separate item that has a reference to the master event's item.  This 
means the note record now has a parentUuid field, which is the uuid of 
the master note.  So instead of including all the note/contentitem 
info(body, triageStatus, reminderTime, etc) in the eventModification 
record, separate contentitem/note records should be used (with the note 
record containing the parent uuid of the master note item).

For example, the eimml for an event with two modifications would look 
something like:

<eim:collection uuid="col1"
                name="Chandler Test"
                xmlns:eim="http://osafoundation.org/eim/0">
  <eim:recordset uuid="item1">
    <event:record xmlns:event="http://osafoundation.org/eim/event/0">
(Continue reading)

Permalink | Reply | 18 comments |
headers
Pieter Hartsook | 1 Mar 2007 06:45
Favicon

Re: Cosmo landing page typos

I can change the copy after we see responses to Ted's suggestions. See
my in-line comments:
>
> From: Ted Leung <twl <at> osafoundation.org>
> Date: February 28, 2007 4:56:20 PM PST
> To: Cosmo Mailing List <cosmo-dev <at> osafoundation.org>
> Subject: [Cosmo-dev] Cosmo landing page typos
>
>
> Hi folks,
>
> I'd like to start a precedent for doing as much work on Cosmo landing pages,
> etc on the cosmo-dev list.   To that end, I want to report a few typos on
> the main page:
>
> * The 0.6 release is Cosmo project's first experimentally usable web
> calendar application. => Cosmo 0.6 is the first release to include an
> experimentally useable web calendar application.
>

"usable" seems to be the preferred spelling rather than "useable",
other than that Ted's suggestion is better because it positions the
web app as a part of Cosmo rather than equivalent to Cosmo.

> * The Cosmo project encompasses both a sharing server as well as web
> application pieces of the Chandler small workgroup collaboration suite. =>
> Cosmo includes both a sharing server and web application pieces of the
> Chandler small workgroup collaboration suite.

encompass is a synonym of include, but I  support using 25-cent words
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jeffrey Harris | 1 Mar 2007 19:41
Favicon
Gravatar

Re: cosmo 0.6.1 EIMML changes

Hi Randy,

> This means the note record now has a parentUuid field, which is the
> uuid of the master note.  So instead of including all the
> note/contentitem info(body, triageStatus, reminderTime, etc) in the
> eventModification record, separate contentitem/note records should be
> used (with the note record containing the parent uuid of the master
> note item).

Gosh, I wish we'd had more in depth notes from our meeting, there was a
lot that was flying by.

We definitely discussed doing this, but my memory is that we ultimately
decided against it and specifically planned on including note fields in
EventModification records.  I think the reason was that we don't want to
send around UUIDs for modifications, because modifications are uniquely
determined by master uuid and recurrence-id, passing around different
Chandler's varying concepts of the modification's UUID is a recipe for
disaster.  So I think the keys for modifications need to be the master's
UUID and the modification's recurrence-id, not the modification's UUID.

It seems OK to me to have a NoteModification record separate from
EventModification, but I'm attached to not passing around UUIDs for
modifications, so in your EventModification example, I think instead of
eventModification:uuid we need eventModification:parentUuid, and in
NoteModification we need to remove the uuid field and add a
recurrence-id field.

Sincerely,
Jeffrey
(Continue reading)

Permalink | Reply | 17 comments |

Gmane