RE: Drupal Puzzle Pieces

[Marc C. <ma...@br...>]

Hey dude

Crazy busy getting ready to split for lala for E3.

Only two comments on this:

- I don't think we have to worry about keeping things internally
represented as FOAF.  FOAF is all about the import/export.  Whatever
efficient way you wanna store things internally - is fine by me.  I know
Drupal has lots of built-in structs.

- You can decide what best order to do things in.  We're (BBM) obviously
interested in being able to point to something as 'PeepAgg' - but you
can best decide how that unfolds.  As you can see from my drawing, DLA
is a separate module and brand - as well.  So 'eventually' we'll want to
have a module (or collection of modules) which can be called the
PeepAgg.  I'm just not up on the politics and reality of extending
modules versus starting from scratch.  How does that work?

=====

http://blogs.it/0100198/DrupalArchRoadmap.jpg

So assuming:
	- Joel gets the pDNS going
	- Chris gets FOAFnet functionality into the drupal.profile
	- you can take it one step further - by turning it into multiple
persona and implementing the goals you map out.
	- so what can we get walkah to do?

- Marc


P.S.  The current live server for 1UP.com is www.ogamo.com  Feel free to
come on by.


-----Original Message-----
From: pee...@li...
[mailto:pee...@li...] On Behalf Of
Jonas M Luster
Sent: Sunday, May 09, 2004 5:15 PM
To: pee...@li...
Cc: Dries Buytaert; Julian Bond; Grant K Rauscher; Nick Chalko; Anca
Mosoiu; crs...@ui...; wo...@ac...; Joel De Gan;
an...@an...; adrian rossouw; Anthony Borders; Danny
Ayers; Brian Dear; wa...@wa...; David L. Sifry; Mitch Ratcliffe;
Neil Drumm; 'Phillip Pearson'; Eric Sigler; Zack Rosen; Marc Barrot;
rich seidner; Ca...@Pe...
Subject: Re: Drupal Puzzle Pieces

> Hopefully we're all in sync and know what we're gonna do - right?

I guess what we're missing is a set of tangible milestones and short 
term design goals. Let me try to outline some of the things I see...

We have a core:

[ core ]

this core holds basic user information, as well as a set of pointers to 
instances:

[ core ]
|   \   \   \   \
[ instances ]

each instance represents a "persona" of the account in question. The 
account can hold an infinite amount of personae, each of which is 
linked to either an internal or an external service, which in turn 
holds data, such as weblog postings, news, images, your bank statement, 
or the list of girlfriends to call next week.

What is needed here:

a) A core
b) Instantiations
and
c) communication protocols between external and internal sources

there are a number of ways, how this could be glued together - FOAF, 
some proprietary system, or something else. I assume you want FOAF.

so here:

                   [ core ]
                  / <----- FOAF glue
[ instance ]
                 \   <----- infoexchange protocol
      [ external or internal source ]

Taking this to tangible milestones:

a) we need a core. The core must be able to transparently address any 
number of instances, all of which should be agnostic towards the data 
they receive and send. In Drupal talk, we need to expand user.module 
and profile.module to include those changes.

b) we need means to communicate and extract info from FOAF data. Again, 
this might be handled by Drupal, and requires something like the 
drupal.module.

c) We need APIs between the external and internal services. This can be 
done by creating a new node-type and attaching the service to it. 
node-types then are tied to personae and all personae are tied to one 
account.

Milestone 1: Make Drupal multi-personae capable
Milestone 2: Ensure Drupal's ability to authenticate against and 
retrieve data from FOAF
Milestone 3: Create node-types and tie them to personae
Milestone 4: Create "commons" module for registered users
Milestone 5: Collect underpants
Milestone 6: ...
Milestone 7: Profit

jonas