Yes, it does make sense. I wonder about the get(), put(), find()
it feels an awful lot like a tuple interface. (01)
* http://citeseer.ist.psu.edu/562746.htm (02)
* http://www-users.cs.york.ac.uk/~aw/pylinda/doc/classlinda_1_1TupleSpace.html
* http://www.cs.berkeley.edu/~ravenben/research/tuplespace/ (03)
Chris Dent <cdent@blueoxen.org> writes: (04)
%
% cc'ing this to the purplewiki devel list as i want this in the
% archive there
%
% On Wed, 11 Aug 2004, John Sechrest wrote:
%
% > When I look at http://purplewiki.blueoxen.net
% > and I try to find the API for the database, I am unable to
% > find any description of how it is intended that people
% > connect to the database.
%
% That's because it hasn't been decided, but discussions do happen
% and are going to happen, but in order for you to participate, you
% probably need to understand the code, because that's the level we
% are at, at the moment.
%
% I'm not suggesting that this is a good thing. It's just the way
% it is.
%
% > If there were some dotted lines that showed the boxes
% > of what is staying and what is going and how the
% > structures are supposed to work, it would be easier to approach.
%
% I think it is likely that everything associated with reading and
% writing wiki pages in the 0.94 and prior versions will go away
% and be replaced by what amounts to a two layer system for
% accessing pages. The top layer will very likely be something very
% similar to find(), get(), put(). Something as simple as
% possible. The next layer down will take those abstractions and
% make it possible to have several different styles of data
% storage, all using the same interface. The first implementation
% (as Eugene has said) will be plain text, because that's the
% simplest to do, and the simplest to inspect and learn from.
%
% You're on the devel list, you've been hearing us say that what is
% there in the code is crap, so you should know it will likely go
% away. You've also been there for our discussions about idiomatic
% and modular interfaces.
%
% You mention that Eugene suggests that support for a text based
% backend is designed in. That's true, it is designed in, in the
% sense that that's what we all (including you) have discussed
% as being desirable.
%
% You then mention that Eugene wants an API and you want
% filesystem access. There's no need for these to be mutually
% exclusive goals, and I think if you were peering behind the door,
% at the code, and at the existing ways of using the wiki and its
% libraries you would know this.
%
% There's nothing preventing the following scenario:
%
% A running wiki that uses the (not yet specified, but desired)
% open database interface is get()ting and put()ing versions of
% pages into a (as far as the interactive levels of the wiki is
% concerned) completely unknown and undescribed filestore.
%
% Meanwhile, you are doing this:
%
% cd /path/to/wiki/filestore
% $EDITOR SomeWikiPage
%
% and it "just works".
%
% Meanwhile, I'm doing this on my mac:
%
% open PersonalWikiEditor WikiPageFoo
%
% and editing content on the same wiki, with xml-rpc, or atom, or
% soap, or something we haven't thought of yet, in a nice brushed
% metal gui thing.
%
% Meanwhile, another person is editing content that is not even in
% the wiki, but uses the same purple number sequence, so the
% content is available to the wiki via transclusion.
%
% I'm now, for your sake, going to go on an extended riff. The
% following may or may not bear any relationship to how things
% eventually turn out, because it may be that as we move forward
% these ideas prove useless. I leave versioning out of this model,
% but I don't see that as a problem. Consider how vms did versions.
%
% The long term design goal is that there be some kind of base
% class or interface for data storage with a Factory of some kind
% that pays attention to a configuration variable that selects
% which subclass of the database class or implementor of the
% interface is used for data storage (similar to the current Search
% and Template systems).
%
% So for wikis in your world you might set a configuration variable
% to be
%
% DataStore: SimpleText
%
% This will give you the benefit of your direct file access (with
% possible risk of concurrent writes causing trouble, but that's an
% issue we'll set aside for the sake of discussion at the moment),
% allowing you to use grep and emacs directly from the command
% without any outside the normal flow of the shell diddling.
%
% A possible disadvantage of such a system is that it could be
% somewhat slow in the face of large numbers of pages, or in
% searching and the like. In this imaginary scenario, I have a wiki
% with several thousand pages and being able to search for strings
% in the content, via the web, is a very important aspect of my
% system. So I've decided to
%
% DataStore: MysqlFreeText
%
% This class implements the database interface, and uses a table
% schema that builds a free text interface of the content of the
% wiki so that the find() operation is quick.
%
% MysqlFreeText is different from the more generic DBIWiki class,
% which uses a slower method to do find().
%
% None of the aforementioned classes are as fancy, though, as
%
% DataStore: Nodal
%
% which is optimized for fast transclusions. get() and put() can be
% used for getting and putting whole wiki pages or for chunks of
% content (identified by purple numbers). Mundane DataStore
% classes, like SimpleText support the node style of interaction by
% wrapping another call to get() or put(), to get a whole page, and
% then parse what's stored into a PurpleWiki::Tree. Nodal bypasses
% that step as it stores pages by purple numbered chunks. get() on
% a node gets the node. get() on a page assembles the page from its
% constituent nodes.
%
% In the event that you are participating in a wiki somewhere that
% is using Nodal, it would be possible for you to still do cat and
% grep style operations on the content, by using tools that access
% the find(), get(), put() operations. I can easily imagine a
% wgrep.
%
% Longer term I believe it would make sense for purplewiki
% libraries to have a config like the following:
%
% DataStoreReader: Nodal SimpleText
% DataStoreWriter: Nodal
%
% That's to support two scenarios:
%
% * A wiki admin has decided to use a different DataStore, but
% rather than shutting the (very busy and special) wiki down to
% convert all the pages, the wiki is configured to be able to
% read multiple formats. The first format is the most desired.
% The list is tried in order. If a get() fails in one, the next
% store is tried. Only when they've all been exhausted does the
% get() fail. put()s go to the primary storage.
%
% * A wiki needs to support, for some reason (despite there being
% lots of other ways to accomplish the same thing), injection or
% replacement of wiki pages by the file system, but wants general
% storage to be Nodal. When files are written into the SimpleText
% store, they are immediately available. When they are edited
% through the wiki they migrate to the nodal system (at some
% level put() will need to be aware of DataStoreReader to perform
% some kind of cleanup).
%
% Did that make sense? If it did, you _are_ beyond the door and in
% the same boat as everybody else and I suggest you just need to
% reconcile yourself to the same frustration the rest of us feel at
% not having the resources to make as much headway on this stuff as
% we would like. If it didn't, spend more time playing with
% PurpleWiki and, maybe even more importantly, associated tools
% such as the blog plugins, perlog, the mhonarc plugin, the
% Apache1Handler and Apache2Handler included in the distribution.
%
% And ask questions that can be answered with shorter answers. Your
% questions are often wildly open ended. I, at least, need
% somewhere to being.
%
% --
% Chris Dent cdent@blueoxen.org
% AIM: sleepleft http://burningchrome.com/~cdent/mt
% It's faith all the way down. We choose reason.
%
% --
% This message is archived at:
%
%
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=tools-yak&i=Pine.OSX.4.53.0408111908040.1559@nitrous.local (05)
-----
John Sechrest . Helping people use
. computers and the Internet
. more effectively
.
. Internet: sechrest@peak.org
.
. http://www.peak.org/~sechrest (06)
--
This message is archived at: (07)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=tools-yak&i=200408120110.i7C1Aww04402@jas.peak.org (08)
|