Mark Jaffe | 2 Aug 2004 22:40
Favicon

Reminder on copyrights...


Please take note when providing updates, that we want to show the 
current year in the copyright line in our source code headers. Before 
checking in any change, please ensure the copyright date is updated to 
2004.

Markie
--

-- 
Mark Jaffe               | (415) 946-3028 (work)
Release Engineer         | (408) 807-2093 (cell)
OSAF                     | (415) 946-3001 (FAX)
markie@... | http://www.osafoundation.org/
PGP Fingerprint: 3435 EB88 6424 F5DF F2CA EF16 2DBF DFEF 143C 1ADE
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
Katie Capps Parlante | 3 Aug 2004 07:03
Favicon

OSAF Office Hours Wednesday 11 AM PST, topic: style guidelines

This is a reminder that the next OSAF Office Hours will be this 
Wednesday, 2 August at 11 AM Pacific time (18:00-19:00 GMT/UTC/Zulu).

This week, we will be talking about Chandler's coding guidlines, what 
we've been learning as we do code reviews, unit tests, and other related 
practices. You can check out the current set of guidelines here:
http://wiki.osafoundation.org/twiki/bin/view/Chandler/ChandlerCodingStyleGuidelines

As always, our Office Hours are at irc.osafoundation.org, channel 
#chandler.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

Katie Capps Parlante | 3 Aug 2004 07:05
Favicon

Re: OSAF Office Hours Wednesday 11 AM PST, topic: style guidelines

oops, make that Wednesday, 4 August at 11 AM Pacific time.

Cheers,
Katie

Katie Capps Parlante wrote:

> This is a reminder that the next OSAF Office Hours will be this 
> Wednesday, 2 August at 11 AM Pacific time (18:00-19:00 GMT/UTC/Zulu).
> 
> This week, we will be talking about Chandler's coding guidlines, what 
> we've been learning as we do code reviews, unit tests, and other related 
> practices. You can check out the current set of guidelines here:
> http://wiki.osafoundation.org/twiki/bin/view/Chandler/ChandlerCodingStyleGuidelines 
> 
> 
> As always, our Office Hours are at irc.osafoundation.org, channel 
> #chandler.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev

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

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

Mitchell Baker | 3 Aug 2004 20:25
Favicon

Notes from Management Committee Mtg of August 3 2004


Can be found at:  
http://wiki.osafoundation.org/twiki/bin/view/Journal/ManagementCommitteeMeetingNotes20040803

Mitchell
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

Mitchell Baker | 3 Aug 2004 20:22
Favicon

Notes from Management Committee Mtg of July 27 2004

Can be found at:  
http://wiki.osafoundation.org/twiki/bin/view/Journal/ManagementCommitteeMeetingNotes20040727

Mitchell
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

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

Pieter Hartsook | 4 Aug 2004 00:42
Favicon

The OSCON 2004 Chandler presentation slide show

In case you didn't make it to the presentation last Wed., at OSCON 2004 
in Portland. Mitch Kapor, Ted Leung, John Anderson, and Brian Kirsch 
presented a panel session: A Developer's Tour of Chandler. The same 
evening all the OSAF developers at the conference attended a BOF session 
to answer questions and meet folks interested in Chandler.

The PowerPoint slides (.ppt -- 4.15 MB) are available at: 
http://www.osafoundation.org/presos/OSAFatOSCON2004.ppt

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

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

Morgen Sagen | 4 Aug 2004 01:40
Favicon

Clouds inspector tool

Having spent some time defining clouds in our schema, I decided I  
needed a tool to help me visualize the cloud definitions (especially  
now that we have cloud/endpoint inheritance) and to easily see what  
items belong to a given item's various clouds.  I modified my  
repository servlet (available either via subversion at  
http://svn.morgen.com/projects/parcels/ or as a tarball  
http://svn.morgen.com/downloads/parcels/parcels-2004-08-03.tar.gz) to  
display more information about items.  If you are running those parcels  
you will be able to point your web browser at  
http://localhost:1888/repo?tool=clouds and get a list of all clouds  
defined in your repository.  Click on any kind and it will show you,  
among other details, all clouds/endpoints that pertain to that kind  
(and which clouds they were inherited from).  For any item it will also  
show all items that are members of that item's cloud(s).  Although it  
won't be running all the time, if you're lucky you might see a running  
instance of this at http://morgen.com:1888/repo/?tool=clouds

Again, to run these parcels yourself, download them, set your PARCELDIR  
environment variable to point to the parcels directory (the parent of  
the morgencom directory) and run Chandler.

If you don't know what clouds and endpoints are, they are Chandler's  
fancy way of specifying what items are "related" to a given item.  The  
repository cloud API is documented at  
http://o11n.org/docs/current/api/repository.schema.Cloud.Cloud- 
class.html , and since the behavior of the cloud framework has changed  
pretty significantly in the past week, I need to update the wiki docs,  
which I'll try to do soon.

~morgen
(Continue reading)

Morgen Sagen | 4 Aug 2004 07:49
Favicon

Re: Copypolicy override on Item instances?


Just to follow up on this issue:  I switched the parcel loader over to 
using cloud-based copying, including the new 'byMethod' include policy. 
  An example of a 'byMethod' method is 
osaf.framework.blocks.Block.BlockEvent.includePolicyMethod( ); it's 
referenced in the Block kind's default cloud.  That method determines 
whether a BlockEvent should be copied by reference or by value on the 
fly, based on the BlockEvent's repository path.

Unless anyone else is still using attribute-based copying, Andi should 
potentially be able to deprecate it.  Are we using attribute-based 
copying anywhere?

~morgen

On Jul 24, 2004, at 2:29 PM, Katie Capps Parlante wrote:

> Hi Donn,
>
> At a recent meeting with Morgen, Ted, Andi, Lisa and John, we decided 
> to depricate copy policy in the data model and to use item clouds 
> instead.   Part of the reasoning for this decision is that we don't 
> want to proliferate a complex suite of policies to group items 
> together (copy, sharing, etc) that complicate the data model. We felt 
> that item clouds were going to be powerful enough for most of the 
> situations where we want to group items together into a larger logical 
> item.
>
> A few improvements to clouds are in the works, including simplified 
> parcel syntax, the ability to name a cloud, and a new "by method" 
(Continue reading)

Donn Denman | 4 Aug 2004 19:39
Picon

Re: Re: Copypolicy override on Item instances?

I'm not using the old copy anywhere.

-Donn

On Aug 3, 2004, at 10:49 PM, Morgen Sagen wrote:

>
> Just to follow up on this issue:  I switched the parcel loader over to 
> using cloud-based copying, including the new 'byMethod' include 
> policy.  An example of a 'byMethod' method is 
> osaf.framework.blocks.Block.BlockEvent.includePolicyMethod( ); it's 
> referenced in the Block kind's default cloud.  That method determines 
> whether a BlockEvent should be copied by reference or by value on the 
> fly, based on the BlockEvent's repository path.
>
> Unless anyone else is still using attribute-based copying, Andi should 
> potentially be able to deprecate it.  Are we using attribute-based 
> copying anywhere?
>
> ~morgen
>
> On Jul 24, 2004, at 2:29 PM, Katie Capps Parlante wrote:
>
>> Hi Donn,
>>
>> At a recent meeting with Morgen, Ted, Andi, Lisa and John, we decided 
>> to depricate copy policy in the data model and to use item clouds 
>> instead.   Part of the reasoning for this decision is that we don't 
>> want to proliferate a complex suite of policies to group items 
>> together (copy, sharing, etc) that complicate the data model. We felt 
(Continue reading)

Andi Vajda | 5 Aug 2004 16:00
Favicon

Core schema change


In order to remove the Kind._getSuperKinds() API, I had to change the core 
schema. Please re-create your repositories after your next cvs update.

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

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


Gmane