Ashley Yakeley | 1 Nov 03:12 2002

[Dev] RDF/Presentation Architecture Suggestion

At 2002-10-31 07:04, Bruce Dykes wrote:

>All I expect from Chandler the application is a clean
>divorce between the presentation layer and the process
>layer.

I'm not sure what role RDF will play in Chandler. But one possibility 
would be to have an "RDF Layer" that deals with the storage and 
transportation (to PDAs, for example) of general RDF, and a "Presentation 
Layer" that interprets the RDF as events, people, email etc. and presents 
it to the user.

The advantage of this is that new RDF applications can easily be 
integrated. For instance, I might want to use Chandler to organise my CD 
collection: I only need write the code that presents a user interface to 
the RDF assertions that represent my data.

--

-- 
Ashley Yakeley, Seattle WA

Michael R. Bernstein | 1 Nov 04:42 2002

[Dev] Python Version?

Does anyone have thoughts as to which version of Python Chandler should
be based on / distributed with?

My inclination is to use the version designated as 'Python in a Tie',
currently scheduled to be based on Python 2.2 . Perhaps the OSAF should
join the Python Business Forum (http://www.python-in-business.org/)?

Cheers,

Michael Bernstein.

Michael R. Bernstein | 1 Nov 04:57 2002

Re: [Dev] ZODB + wxPython framework

On Mon, 2002-10-28 at 21:34, Michael R. Bernstein wrote:
> I just ran across this desktop application framework called PyFrame:
> http://www.pyframe.com/
> 
> Seems like it could be vaporware, but I'm CC'ing the contact email for
> the site just in case.
> 
> If it's *not* vapor, it looks promising, and may be useful for
> developing Chandler.
> 
> Or not.
> 
> Michael Bernstein.

I received a reply from Jeff Sasmor, the developer of PyFrame, but
though he CC'd the list, I didn't see his reply here, so I'm forwarding
it back to the list.

-----Forwarded Message-----

From: Jeff Sasmor <jsasmor@...>
To: Michael R. Bernstein <webmaven@...>, dev <at> osafoundation.org
Subject: Re: ZODB + wxPython framework
Date: 29 Oct 2002 08:52:11 -0500

It's not vaporware, but if you note on the title page of the website,
it won't be available till sometime next year. The alpha versions of 
it are quite operational, but there are a number of key features
that aren't implemented yet.

(Continue reading)

Michael R. Bernstein | 1 Nov 07:55 2002

Re: [Dev] RDF and ZODB

Ok, given what little I know about Chandler's proposed use of RDF stored
in the ZODB, I went hunting for the RedFoot developers to ask them about
their library. I caught up with Eikon on the #redfoot IRC channel.

I started by assuming that triples needed to be represented by class
instances and stored somehow, but this turns out not to be the case. A
triple really only consists of references to a subject, predicate, and
object, so the RDFLib triple store uses nested dictionaries to store
triples. Each triple is stored in two sets of nested dictionaries as
follows:

spo[s][p][o] = 1
pos[p][o][s] = 1

(s)ubject, (p)redicate, (o)bject.

Persisting very large dicts in the ZODB is usually a bad idea, because
in order to access a key/value pair, the whole dict needs to be loaded
into memory. So, the ZODB has a more efficient persistent data type
called a BTree (Binary Tree). The ZODB BTree implementation has the same
API as a dict, so can more or less be used as a dict replacement, but
BTrees are ordered (like lists) so getting the correct value by key only
requires loading the branch of the tree that leads to the key/value
pair.

BTree documentation can be found here:
http://www.zope.org/Members/ajung/BTrees/FrontPage

Anyway, Eikon downloaded the Standalone ZODB package
(http://www.zope.org/Products/StandaloneZODB) and in a couple of hours
(Continue reading)

philsc | 1 Nov 16:47 2002

[Dev] Re: Dev -- confirmation of subscription -- request 957020

> Dev -- confirmation of subscription -- request 957020
>
> We have received a request from 158.155.0.74 for subscription of your
> email address, <philsc@...>, to the dev <at> osafoundation.org
> mailing list.  To confirm the request, please send a message to
> dev-request@..., and either:
>
> - maintain the subject line as is (the reply's additional "Re:" is ok),
>
> - or include the following line - and only the following line - in the
> message body:
>
> confirm 957020
>
> (Simply sending a 'reply' to this message should work from most email
> interfaces, since that usually leaves the subject line in the right
> form.)
>
> If you do not wish to subscribe to this list, please simply disregard
> this message.  Send questions to dev-admin@...

Anthony Barker | 1 Nov 19:43 2002

[Dev] COM &UNO Integration

There are lots of component architectures around: corba/com/xpcom/uno

I am interested in integration with COM(windows apps) and UNO(openoffice)
particularly.

I am assuming that it should be fairly easy to call com via python and
mark hammonds win32 extensions
http://starship.python.net/crew/mhammond/

But this is on windows only - on other platforms it gets trickier:

There is a pyUNo project
http://polysorbate.org/?work/pyuno

There is also a COM-UNO mapping
http://udk.openoffice.org/common/man/draft/com_lang_spec.html
(I have read some developers complaing about this one.)

Any thoughts?

Anthony
http://xminc.com/linux

Chris Allum | 1 Nov 23:23 2002
Picon

[Dev] Rule System was: Re: Rules Discovery

[cross posting to dev list]

This sounds like a good approach.

There should be a API that rule scripts can use to get specific 
information about a message (particular header, or body), and set 
information as appropriate, such as indicating which category it should 
belong in.

For example (in no particular language):

script filter_message ( message_id ) {
	get "from" header for message_id // a Chandler API
	get body for message_id
	
	// do some processing
	
	if ( ... ) {
		add category "Personal" to message_id // some more
		do not apply more rules to message_id // example API's
	}
}

Of course this could be provided through the 'wizard' interface.

These scripts could have access to a statistical filtering package 
(clippy) as either part of the Chandler API or some external package.

Chris

(Continue reading)

joel finkle | 2 Nov 01:29 2002
Picon

[Dev] Re: [Design] Rule System was: Re: Rules Discovery

>From: Chris Allum There should be a API that rule scripts can use to... set 
>information as appropriate, such as indicating which category it should 
>belong in.
...
>		add category "Personal" to message_id // some more
>		do not apply more rules to message_id // example API's

Just a suggestion, but I don't trust my computer to do things intelligently. 
  I'd like categories of "Personal" when I assign it, and "Probably 
Personal" when Chandler assigns it, then make the computer happier when I 
agree with it (strengthen the weights of the statistical filter) and promote 
it to "Personal".

_________________________________________________________________
Get a speedy connection with MSN Broadband.  Join now! 
http://resourcecenter.msn.com/access/plans/freeactivation.asp

Michael R. Bernstein | 2 Nov 01:52 2002

[Dev] Re: [Design] Vista prototype

(moving over to Dev)

On Fri, 2002-11-01 at 15:57, Patrick Phalen wrote:
> 
> On Friday 01 November 2002 12:00, Brian Siano wrote:
> >
> > Mitch probably knows this part already, but for everyone else, where's what
> > I'm talking about. Remember, in Ecco, the term "Folder" referred to the
> > same thing as a "data fields." If an Item was "placed in the Phonebook
> > Folder," it meant that that Item had a value in the data field called
> > "Phonebook."
> >
> > In Ecco, one could create something like a "package" by arranging the
> > Folders in a hierarchical fashion under another Folder. For example, for
> > the Phonebook, there was a Checkmark folder called "Phonebook." And in the
> > Folder view, one could arrange all of the various contact-oriented data
> > fields as sub-folders under the "Phonebook" folder. This enabled a user to
> > have a "Phonebook" column display, rather than a checkmark, a list of those
> > Folders in which that particular Item had data. (I've attached a JPG file
> > illustrating this-- note that the same folder, "Phonebook," can be
> > displayed in two ways.)
> >
> > In a sense, this ability to arrange the folders hierarchically was a kind
> > of "Package." So were Ecco's "Forms," which were basically lists of
> > specific Folders that one could enter data into without leaping all around
> > the data structure.
>
> The Ecco feature which Brian describes sounds reminscent of Gil and Lorenz's 
> concept of Environmental Acquisition, a powerful notion, discussed here in 
> one of Jon Udell's Byte columns: 
(Continue reading)

Daniel Krech | 2 Nov 02:27 2002

Re: [Dev] RDF and ZODB

On Fri, 2002-11-01 at 01:55, Michael R. Bernstein wrote:

<snip/>

> Anyway, Eikon downloaded the Standalone ZODB package
> (http://www.zope.org/Products/StandaloneZODB) and in a couple of hours
> had successfully modified his in-memory triple store to use BTrees
> inside a ZODB instance.

I will make the next release of RDFLib[1] by this coming Tuesday. The
release will include the ZODB BTree backed TripleStore along with a
number of other changes. If you have any questions before then (or
after) feel free to stop by #redfoot (see instructions on the Redfoot[2]
homepage)

--eikeon, http://eikeon.com/

[1] http://rdflib.net/ 
[2] http://redfoot.net/


Gmane