The biggest vision here is to mix the Wiki Name namespace idea with the use of Structured Data. So, instead of Bill Seitz being just a document page, it's a contact record, which of course has a note field. It's a PIM with easily-generated Intertwingularity. (initial thoughts 2002)
One conceptual problem here is that lots of tiny nodes don't really warrant a Wiki Name. Do I want a Wiki Name for every meeting/event in my calendar? Maybe I have a generic-name-generation scheme that uses an object type plus an integer ID. Then the user can optionally assign a (unique) WikiName if he wants.
Types of data:
- documents, notes, thoughts (conventional wiki; BeOS and ReiserFS File System)
- PIM records (just use YAML for structured data specification?)
- calendar meetings, events
- to-dos (stand-alone, or with projects: see Project Flux)
This reminds me a bit of LifeStreams.
See ZopeCMF proposal for OrganizationObjects (http://cmf.zope.org/rqmts/proposals/OrganizationObjects). The challenge is to provide for tracking of organizational information in a general way that applies across content types, providing for consistent implementation of relationships as they are discovered to be useful.
Given that there are multiple focuses here (messaging, Knowledge Management, PIM), should these be split up? Probably yes. Could a Web Services model allow different people to develop different apps, which could be reasonably well-integrated? Probably not, probably want more-integrated data layer. But I don't know anything about this fancy design stuff (oh Dave McCusker!!)...
- I want to be able to treat all stuff (email, documents, etc.) as a single soup
- not all the pieces can come from a single app vendor
- I want a platform where "basic" users are comfortable performing their basic tasks. (So there are requirements for "packaged" software/services providing usability, reliability, and scalability.)
- I want this to be a viable EcoSystem, so it needs to allow for many vendors and experiments. (e.g. having to jump through hoops to integrate EMail, the way products like LifeStreams work with MsOutlook, are bad)
- for a given narrow app to be "open" enough to be in this mix, should it expose specific methods (which limits me to the methods it chooses to make open) or should it just use an underlying data system which is itself open (e.g. MetaKit) (which seems more fragile)?
- should we plan right away on making the data layer distributed? See Semplesh.
- is it true that processing should happen "close to" (e.g. on the same machine as) the data?
- does it make sense to have a "soup proxy" (which sucks data from various vertical servers) (maybe in some cases client apps talk to the soup server, in other cases they continue to talk directly to the vertical servers, and the soup server has to stay in synch)
Log of graph-app toe-dipping
Context: really want to be building Project Flux. But I think first step is to find back-end Data Store that thinks like Everything Is A Graph. So a lightweight hack Object Browser is a first step for getting my feet wet.
- install Active Python
- play with Jeremy Bowers' outliner code, email him some thoughts. Read his critique of Buzz Outliner, decide to not touch it. Take a look at the LEO outliner screenshots, decide to ignore it.
- install RedFoot. Have to install RDFLib and Medusa first. Can't get things launched, realize that putting Medusa inside /python22/Tools/ probably means it's not getting imported. Recall my history of confusion with Python Path, sys.path, etc.
- try to use Python Win to browse the Python Path, this blows up Python Win.
- Do some Python Win Python Path research on ASPN, find unanswered similar posting contact its author, plus support.
- Decide to ignore that issue for now, wait for responses.
- move Medusa into /python22/Lib/ - now can start RedFoot (though if launching from command line have to be in the /Lib/site-packages/ directory)
- take a look at the generic app. Looks kinda interesting, but discover Apps are generally written in redcode, which is yet another horrifying tag-based language. Thank you for playing. Though I may be over-reacting. Actual modules can be written in straight Python. What I need to see if a semi-real sample app...
- fundamental meta-issue is whether I want to be using RDF for this, vs [E4Graph]... on the one hand RDF smells like it will offer greater interop with other stuff down the road, on the other hand it seems so immature right now (e.g. no standard query language accepted) that I feel like it will be even more confusing than just going alone to sort out some ideas. Silly conclusion: will probably base choice of path on combo of (a) finding decent starter apps to get me bootstrapped, and (b) where I hit a brick wall...
- sample RedFoot apps: file:example.init, http://redfoot.net/2002/07/examples/hello_world.init, http://redfoot.net/2002/07/examples/generic.init
- checked out IRC, found that examples are in http://redfoot.net/2002/07/examples/ and http://redfoot.net/2002/07/redmodules/
- also FOAF functionality at http://eikeon.com/foaf/ is packaged at http://redfoot.net/2002/07/25/
- and it was recommended to avoid recode approach for now, and instead follow http://redfoot.net/2002/07/examples/link_app.py
- and you can browse the IRC archives at http://redfoot.net/chat/
- read some FOAF documentation
- try the example FOAF RedFoot app. Note that its dataset isn't consistent with the public FOAF server (both in list of entries, and in data for a given person).
- try to play with link_app.py. Establish need to call as 'python .../redfootlib.py sniffer.init'
- hosed by pythonpath problems, which always annoy me - have to get redfootlib added to the path
- starting to think that RDF is just another layer of immature complexity, so want to get closer to a raw Data Store.
Oct1: reconsider why I'm doing this. On further thought, if I were staying in single-user mentality, I'd just use a wiki and not worry much about structure. If I think in Collaboration Ware terms, it becomes lots messier and requires a BootStrapping model. So why am I still obsessed?
- lite: for Sharp Zaurus, other non-Zope users
- have all notes on zaurus, with same interface
- non-modal Rich Client
- PIM alt to Palm Desktop, MsOutlook
- not sure Project Flux should be ASP (vs P2P)
- avoid Zope confusion (changing to v3 could get ugly)
Feb2003 thoughts - see NodeWeb