schema version number and branches

It just occurred to me that we need to be careful with the domain
model's schema version (application.Utility.SCHEMA_VERSION) and
branches. It seems it is a string so it should be easy to settle on a
syntax.

So, for trunk, I think continuing as we have is fine.

For branch, I suggest the value should be of the form "branch-number".
When a branch is initially created, it does not need to be changed, but
when a change that requires SCHEMA_VERSION change it should be changed
to the branch version.

--

-- 
  Heikki Toivonen

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

0.6.1 release update

Folks,
We have the 0.6.1 release coming up. The release date for 0.6.1 has  
been set to Feb 9th.
The list of approved and nominated 0.6.1 blocking bugs is linked from  
development home page:

http://wiki.osafoundation.org/bin/view/Projects/DevelopmentHome

Only the bugs flagged "blocking0.6.1+" will be fixed in this release.  
If you have a blocking bug assigned to you, please take it as a  
higher priority and fix it soon.
We are hoping to do the final 0.6.1 release candidate builds on Mon,  
Feb 6th. That will give us good 3 days to regress the builds and test  
it on all supported platforms before the release.

Questions/concerns? Let us know.
Aparna

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Re: Scoping out sharing-related 0.7 projects

Morgen Sagen wrote:

> (B) User Notifications:  I'm not sure if I'm talking about what has  
> been referred to as "big-N Notifications", but clearly what is needed  
> for sharing is some way for the user to see a log of changes that  
> happened as a result of syncing.  Currently you can see such changes  
> flash by quickly in the Sync dialog, but Mitch proposed the idea of  
> having a sidebar collection which acts much like an RSS feed of  
> changes.  We could add a new Kind to the domain model named  
> "UserNotification" (or some name to distinguish it from any internal  
> notifications). Changes made in the background during syncing would  
> get a corresponding UserNotification item added to the Changes  
> collection.  The user could then, at their leisure, scan through the  
> changes via the list view of that Changes collection, and either mark  
> each UserNotification as "read" or else delete the UserNotification  
> item.  This same mechanism could be used not just for sharing-related  
> changes, but for any kind of thing that needs to be brought to the  
> user's attention in a non-immediate manner.  These UserNotifications  
> could be fed into a single collection, or multiple collections,  
> depending on preference.  This requires from CPIA: (1) a way to sort  
> the list view, and (2) some sort of 'mark as read' facility.

I don't like this idea of an RSS collection to post what are basically 
activity log info. Internally, I'm fine with having those info treated 
as items (of a relevant kind as mentioned here above) but, from an end 
user standpoint, this is a very different kind of info, not relevant to 
"tasks" or "projects" but rather to the internal health of the 
application/system.

Re: [Dev] Scoping out sharing-related 0.7 projects

On Jan 31, 2006, at 8:45 PM, Philippe Bossut wrote:

>
>
> Morgen Sagen wrote:
>
>> (B) User Notifications:  I'm not sure if I'm talking about what  
>> has  been referred to as "big-N Notifications", but clearly what  
>> is needed  for sharing is some way for the user to see a log of  
>> changes that  happened as a result of syncing.  Currently you can  
>> see such changes  flash by quickly in the Sync dialog, but Mitch  
>> proposed the idea of  having a sidebar collection which acts much  
>> like an RSS feed of  changes.  We could add a new Kind to the  
>> domain model named  "UserNotification" (or some name to  
>> distinguish it from any internal  notifications). Changes made in  
>> the background during syncing would  get a corresponding  
>> UserNotification item added to the Changes  collection.  The user  
>> could then, at their leisure, scan through the  changes via the  
>> list view of that Changes collection, and either mark  each  
>> UserNotification as "read" or else delete the UserNotification   
>> item.  This same mechanism could be used not just for sharing- 
>> related  changes, but for any kind of thing that needs to be  
>> brought to the  user's attention in a non-immediate manner.  These  
>> UserNotifications  could be fed into a single collection, or  
>> multiple collections,  depending on preference.  This requires  
>> from CPIA: (1) a way to sort  the list view, and (2) some sort of  
>> 'mark as read' facility.
>
> I don't like this idea of an RSS collection to post what are  

Interesting article on how to (and how *not* to) get crash reports on OS X

Daring Fireball article:  
http://daringfireball.net/2006/01/smart_crash_reports

Way down deep in the article is a small excerpt of how to do it 
"properly":

> Other developers have devised their own systems. Michael Tsai’s 
> C-Command family of apps all contain a custom crash reporter, 
> MJTCrashReporter, of his own design. Even though I use SpamSieve and 
> BBAutoComplete constantly, and I beta test both applications, I have 
> never seen either of them crash — so I’ve never actually seen Tsai’s 
> crash reporter in action. I asked him how it works, and he replied:
>
>> When the application starts up, it uses signal (3) to  register for 
>> the signals that indicate crashes. When the app  crashes, it calls 
>> the signal handler, which launches  MJTCrashReporter and then quits 
>> the app. MJTCrashReporter waits  a second or two to give the system 
>> time to write the crash log  file, then it brings up its crash 
>> reporter window, pre-filled  with the default address from Address 
>> Book and the latest crash  log. To send the report, it makes an HTTP 
>> POST to  c-command.com. I treat most crash reports as regular tech  
>> support issues, so I have the server send them to me as e-mails  with 
>> the user’s address in the reply-to.
>
> Absolutely beautiful. Also: doesn’t interfere a whit with any other 
> software on the system. Tsai also pointed out another advantage to 
> rolling one’s own crash reporter system: backwards compatibility. 
> Unsanity’s SCR only works on 10.4 or later; Tsai’s works all the way 
> back to Mac OS X 10.2, which his applications still support.

Re: schema version number and branches

On Tue, 31 Jan 2006, Heikki Toivonen wrote:

> It just occurred to me that we need to be careful with the domain
> model's schema version (application.Utility.SCHEMA_VERSION) and
> branches. It seems it is a string so it should be easy to settle on a
> syntax.
>
> So, for trunk, I think continuing as we have is fine.
>
> For branch, I suggest the value should be of the form "branch-number".
> When a branch is initially created, it does not need to be changed, but
> when a change that requires SCHEMA_VERSION change it should be changed
> to the branch version.

Indeed. I suggest we use the same letter(s) used in the BP (so-called branch 
prefix) I introduced a few months ago with my branch. The BP is set in
chandler/Makefile and in external/Makefile.inc.
On my branch, for example, this version number would become "a139"

Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev

Re: Projects for OSU

A consolidated list of proposed projects is available here <http:// 
wiki.osafoundation.org/bin/view/Journal/TedLeung20060127>.   If you  
have any additional ideas. please add them there.  I'd like to get a  
preliminary version of this list to the OSL folks by the end of this  
week.

Ted

On Jan 23, 2006, at 3:58 PM, Ted Leung wrote:

> Hi all,
>
> One of the things we're trying to do in the community space is to  
> try and hook up with people who could contribute on a sustained  
> basis.  One avenue for doing this is via Oregon State University's  
> (OSU) Open Source Lab (OSL).    Among other things, the OSL has  
> graduate students who are (right now!) looking for master's degree  
> projects, which means a 20+hr/wk project that could last  as long  
> as 2 years.
>
> I'd like to see whether we can think of any projects that:
> 1) could contribute to getting Chandler/Cosmo/Scooby out the door  
> faster (perhaps in an area where we aren't planning to do a lot of  
> work right away).
> 2) could be done by someone at OSL in conjunction with some  
> mentoring/support from the Chandler community / OSAF staff.
>
> As examples, these are some Mozilla projects that were suitable as  
> projects for OSL students
>

Subscribing to calendar URLs

On IRC earlier today, we had a user, Leppy, unable to subscribe to  
his Basecamp calendars (see <http://basecamphq.com/>) from Chandler;  
both Mozilla and Apple iCal both had no problems.

What's going on here is that Chandler is getting itself confused  
about what kind of thing you're trying to subscribe to. It could be  
any of:

   1. A simple text/calendar resource (i.e. a ".ics file on the web").
   2. A non-CalDAV Chandler WebDAV collection (i.e. cloud xml)
   3. A CalDAV collection

It turns out that we don't really detect the first case very well; in  
fact, if you're not subscribing to a URL that ends in ".ics",  
Chandler won't allow you to subscribe, and will fail with a fairly  
incomprehensible error.

While I'm working on making this code work better (i.e. correctly) in  
0.7, it seemed to me that we could make a simple change in the  
sharing code for 0.6.1 that would enable more users to subscribe to  
shared calendars:

Basically, if the URL being subscribed to is using the 'webcal'  
scheme, we should assume case #1 above. This would fix the user's  
problem, at least, and others where calendars get shared with a  
webcal: scheme but no .ics extension.

FWIW, the webcal scheme is not an official standard; rather I think  
it's something Apple made up, but has become fairly widespread nowadays.

Re: Subscribing to calendar URLs

On Feb 1, 2006, at 2:06 PM, Grant Baillie wrote:

> On IRC earlier today, we had a user, Leppy, unable to subscribe to  
> his Basecamp calendars (see <http://basecamphq.com/>) from  
> Chandler; both Mozilla and Apple iCal both had no problems.
>
> What's going on here is that Chandler is getting itself confused  
> about what kind of thing you're trying to subscribe to. It could be  
> any of:
>
>   1. A simple text/calendar resource (i.e. a ".ics file on the web").
>   2. A non-CalDAV Chandler WebDAV collection (i.e. cloud xml)
>   3. A CalDAV collection
>
> It turns out that we don't really detect the first case very well;  
> in fact, if you're not subscribing to a URL that ends in ".ics",  
> Chandler won't allow you to subscribe, and will fail with a fairly  
> incomprehensible error.
>
> While I'm working on making this code work better (i.e. correctly)  
> in 0.7, it seemed to me that we could make a simple change in the  
> sharing code for 0.6.1 that would enable more users to subscribe to  
> shared calendars:
>
> Basically, if the URL being subscribed to is using the 'webcal'  
> scheme, we should assume case #1 above. This would fix the user's  
> problem, at least, and others where calendars get shared with a  
> webcal: scheme but no .ics extension.
>

Re: Subscribing to calendar URLs

+1 for a quick and dirty fix in 0.6.1 based on checking for a webcal scheme.

Morgen Sagen wrote:
> 
> On Feb 1, 2006, at 2:06 PM, Grant Baillie wrote:
> 
>> On IRC earlier today, we had a user, Leppy, unable to subscribe to his
>> Basecamp calendars (see <http://basecamphq.com/>) from Chandler; both
>> Mozilla and Apple iCal both had no problems.
>>
>> What's going on here is that Chandler is getting itself confused about
>> what kind of thing you're trying to subscribe to. It could be any of:
>>
>>   1. A simple text/calendar resource (i.e. a ".ics file on the web").
>>   2. A non-CalDAV Chandler WebDAV collection (i.e. cloud xml)
>>   3. A CalDAV collection
>>
>> It turns out that we don't really detect the first case very well; in
>> fact, if you're not subscribing to a URL that ends in ".ics", Chandler
>> won't allow you to subscribe, and will fail with a fairly
>> incomprehensible error.
>>
>> While I'm working on making this code work better (i.e. correctly) in
>> 0.7, it seemed to me that we could make a simple change in the sharing
>> code for 0.6.1 that would enable more users to subscribe to shared
>> calendars:
>>
>> Basically, if the URL being subscribed to is using the 'webcal'
>> scheme, we should assume case #1 above. This would fix the user's
>> problem, at least, and others where calendars get shared with a