Pieter Hartsook | 2 Apr 03:06 2003

FW: OSAF receives $98,000 grant from the Andrew W. Mellon Foundation

OSAF is pleased to announce that the Andrew W. Mellon Foundation has agreed
to provide a $98,000 grant to fund a planning project to extend OSAF's
Chandler software application to meet the information technology needs of
higher education.

We originally planned for Chandler to target individual and small-to-medium
business users that need a better tool to manage and share their email,
contacts, calendars and notes. Based on expressions of significant interest
from the higher education community, OSAF, with support of the Mellon
Foundation, is undertaking a study of how to address administration
scalability, and security issues of that segment.

We are still focused on our original target of supporting small-to-medium
groups in a decentralized fashion.  However, if it looks feasible and we are
able secure the funding, OSAF would create the Chandler functionality
required by higher education institutions to work with campus computing
infrastructure and requirements.  Whether this would be done via a single
version of Chandler or two separate versions is still to be determined.  Our
investigation into the higher educational requirements has already led us to
improve our initial architecture design to improve robustness and
scalability in centralized and decentralized environments alike.

You can see the announcement on the OSAF
website(http://www.osafoundation.org/MellonAnnouncement_Mar-31-2003.htm)

Pieter Hartsook
Marketing Specialist
Open Software Applications Foundation

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
(Continue reading)

petite_abeille | 4 Apr 23:18 2003
Picon

Re: db topics page now public in jungle


On Wednesday, Mar 26, 2003, at 23:56 Europe/Zurich, rys mccusker wrote:

> http://wiki.osafoundation.org/bin/view/Main/OsafDbTopics
>
> some of this page is database requirements, and some of it is talking
> points we needed to keep in mind during design problems.

Does those "requirements" means that you guys are going to roll your 
very own database of sort?!!?!?!???

With your own peculiar querying language? Transactions? Indexing? 
Access control?

I sincerely hope not.

PA.

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

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

petite_abeille | 4 Apr 23:27 2003
Picon

Re: oid coinage problem


On Friday, Mar 28, 2003, at 02:22 Europe/Zurich, rys mccusker wrote:

> http://wiki.osafoundation.org/bin/view/Main/DbOidCoinageProblem

"If ten clients use the same database at the same time, and each client  
attempts to assign unique IDs, nothing really prevents collisions in  
the IDs chosen by clients. "

Why would that be?

http://www1.ics.uci.edu/~ejw/authoring/uuid-guid/draft-leach-uuids- 
guids-01.txt

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

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

rys mccusker | 5 Apr 00:31 2003

Re: rolling your own (db topics page)

petite_abeille wrote:
> 
> On Wednesday, Mar 26, 2003, at 23:56 Europe/Zurich, rys mccusker wrote:
> 
>> http://wiki.osafoundation.org/bin/view/Main/OsafDbTopics
>>
>> some of this page is database requirements, and some of it is talking
>> points we needed to keep in mind during design problems.
> 
> Does those "requirements" means that you guys are going to roll your 
> very own database of sort?!!?!?!???

if that was the message, I think we would have said that somewhere.

the purpose of the requirements was to shoot down lame suggestions by
people who say, "why don't you just use XYZ?" when XYZ does not handle
something we want covered in Chandler.

or rather, the purpose is to tell someone they need to implement missing
features we need if we adopt their favorite database.  Same thing.

the short answer to your question is this: we might roll her own.  But,
we have no intention of rolling our own soon.

Instead, we want to get operating using as little newly written code
as possible.  And yet, we would like pluggable interfaces, so that parts
of our system can be replaced piecemeal with something that works better.

basically, the goal is to use off-the-shelf components, and the goal is
also to permit ourselves to roll our own whenever we feel like it.  And
(Continue reading)

rys mccusker | 5 Apr 00:42 2003

Re: oid coinage problem

petite_abeille wrote:
 > Why would that be?
 >
 > http://www1.ics.uci.edu/~ejw/authoring/uuid-guid/draft-leach-uuids-
 > guids-01.txt

what if the clients do not use globally unique ID algorithms for
inventing new object IDs?

let's ignore the possibility that using globally unique IDs alone
would actually be attractive to someone.  Let's assume people want
simple ascending integers for simplicity, or want low-cost ID
generation -- perhaps because of high frequency object creation.

I have not yet added to that page the additional material due to
and all flight interchange with a friend who suggested some ID
allocation schemes which allocate blocks of IDs to permit them
to be some allocated by clients after getting an entire block.

Rys

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

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

Bill Seitz | 5 Apr 01:24 2003

Moz/Minotaur implications?

Does the new Moz's roadmap, emphasizing Minotaur for mail/news, require 
any re-thinking about the plan to build email capabilities into 
Chandler, vs integrating with it (or tweaking it)?
http://webseitz.fluxent.com/wiki/z2003-04-04-MozillaReorg
(or maybe it will just provide some smaller components to use)

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

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

petite_abeille | 5 Apr 01:21 2003
Picon

Re: oid coinage problem


On Saturday, Apr 5, 2003, at 00:42 Europe/Zurich, rys mccusker wrote:

> what if the clients do not use globally unique ID algorithms for
> inventing new object IDs?

Why not?

>
> let's ignore the possibility that using globally unique IDs alone
> would actually be attractive to someone.

Why?

>  Let's assume people want
> simple ascending integers

Why?

>  for simplicity,

How is that simple?

>  or want low-cost ID
> generation

How is centralizing id creation "low-cost"?

>  -- perhaps because of high frequency object creation.

(Continue reading)

rys mccusker | 5 Apr 02:20 2003

Re: oid coinage problem

I thought the why? why? why? thing was a children's game.

I don't mean to be rude, but I don't see why I should supply answers
that are longer than your questions. (but if your questions are longer,
I won't have time to answer them.)

petite_abeille wrote:
>> what if the clients do not use globally unique ID algorithms for
>> inventing new object IDs?
> 
> Why not?

you will force them how?

>> let's ignore the possibility that using globally unique IDs alone
>> would actually be attractive to someone.
> 
> Why?

I like globally unique IDs.

>>  Let's assume people want  simple ascending integers
> 
> Why?

ask John Anderson.  I didn't do it.

>>  for simplicity,
> 
> How is that simple?
(Continue reading)

Bill de hÓra | 5 Apr 12:00 2003
Picon

Re: oid coinage problem

rys mccusker wrote:
> petite_abeille wrote:
>  > Why would that be?
>  >
>  > http://www1.ics.uci.edu/~ejw/authoring/uuid-guid/draft-leach-uuids-
>  > guids-01.txt
> 
> what if the clients do not use globally unique ID algorithms for
> inventing new object IDs?

Yes, implementing a GUID generator is tricky. One option is to let 
the client ask the server to provide them as a service.

> let's ignore the possibility that using globally unique IDs alone
> would actually be attractive to someone.  Let's assume people want
> simple ascending integers for simplicity, or want low-cost ID
> generation -- perhaps because of high frequency object creation.

You can pool GUIDs. Once you have a proper generator, it's not like 
they're a valuable resource. On the other hand if you want to use 
them as database keys there are issues with performance, or if you 
want to do sorts there are some limitations involved.

> I have not yet added to that page the additional material due to
> and all flight interchange with a friend who suggested some ID
> allocation schemes which allocate blocks of IDs to permit them
> to be some allocated by clients after getting an entire block.

An alternative to Leach and Salz is the TagURI scheme:

(Continue reading)

petite_abeille | 5 Apr 12:23 2003
Picon

Re: oid coinage problem


On Saturday, Apr 5, 2003, at 02:20 Europe/Zurich, rys mccusker wrote:

> I thought the why? why? why? thing was a children's game.

Right... and how will you qualify making up random assumption? 
Grownup's game?-)

>
> I don't mean to be rude, but I don't see why I should supply answers
> that are longer than your questions. (but if your questions are longer,
> I won't have time to answer them.)

Same difference then.

>
> petite_abeille wrote:
>>> what if the clients do not use globally unique ID algorithms for
>>> inventing new object IDs?
>> Why not?
>
> you will force them how?

It's part of your spec: oids are uuids.

>
>>> let's ignore the possibility that using globally unique IDs alone
>>> would actually be attractive to someone.
>> Why?
>
(Continue reading)


Gmane