Tags:
store1Add my vote for this tag create new tag
, view all tags
InterfaceThread - FeaturesThread

Related: OfflineWiki, ReadWriteOfflineWiki, WikiClusters, WebsitePublishing, NonWebAccessToWiki, TWikiWithCVS, TWikiXML, LoadTesting, GenericMetaDataStoreForTopics

First step to creating the means for solving some of the above discussion is seperating the file access (currently rcs) out of the main wiki.pm code base. Then encapsulating it with some external internal.

This interface would need to provide based on the current code. Given a particular Web:

  • version information
  • pre-output parsed text given a version
  • author information
  • diffs

Furthermore things like

should be possible to bolt/design on top.

Initial steps involve simple extracting the current code from wiki.pm and putting them into a seperate package.

-- NicholasLee - 12 Jun 2000

[ Unfortunately some prior comments by Peter and myself where lost in the Sourceforge disaster a while back. ]

These ideas represent some thoughts I've had with regards to the abstraction of the file access layer. They further extend up into the Presentation layer.

Note I'm aiming at the following core functionality:

Given the above feature requirement set I hope to be able to provide a generic file driver interface. ie. It should be possible to do TWiki::Store::DBI, TWiki::Store::CVS and maybe TWiki::Store::Cluster.

These ideas will be reliant on perl object oriented features, so there will be performance drawbacks to these methods. It remains to be seen how much these actually are and whether to ability to easily create a mod_perl version plus the increase functionality will out-weight the penalities.

There are three basic concepts I'm working with at the moment:

PackageTWikiStore is intended as a low-level driver interface and provider of TWikiTopic handles. PackageTWikiTopic is intended as a middle-level handle provides things like 'version lists', author information and the actual read/lock/save access to the TWikiStore.

Meta-information is essentially a low level key-value store associated with a Topic. Things like version lists, access control and whatever further meta-information might be easily extended and attached to a Topic. We could use something like Web.Web.THIS to provide a handle to per Web meta-information.

Apart from a well define set of meta-information to met the requirements above in a generic manner, an implementation of a TWikiTopic would be able to add further meta information. So for instance the current TWiki::Store::RCS would export author information as it does now, but TWiki::Store::CVS would be required to insert the author meta-information into the actual file or some other location. Similar methods might be used with a DBI driver.

So a meta-information interface provides a generic means to abstract the details away from a TWiki::Topic.

An example of the high level use of these ideas in say cgi-bin/view:

my $store = new TWiki::Store::RCS("something or rather");

my $topic = store->topic_handle("web.web2.Topic");  # maybe some options to say read-only to improve performance
 
my @versions = @{ $topic->version_list };

# Do something with that.

my @access_list = @{ $topic->access_list };

# Do something with that.


my $renderObject = new TWiki::PurpleRenderer( something ... ) #  see later
 
print $renderObject->render($topic);
 
# or
 
print $renderObject->render($topic->version('1.1'));

Note the Render bit at the end is somewhat vague. See me comments at BetterTWikiTagTemplateProcessing for an idea of where I think it could go.

Feedback on this would be good, there isn't actually any serious code at the moment as I've been caught up with other work.

-- NicholasLee - 23 Jul 2000

You could potentially provide access to everything via TWiki::Store with different Topic drivers and based on meta-information hints.

So for instance you could provide a mechanism to version, edit and store template files.

-- NicholasLee - 23 Jul 2000

An API is developing under the work in TWikiModularizationCvsBranch. Due course it will be published here for discussion and review.

-- NicholasLee - 31 Mar 2001

(MichaelUtech comments Refactored from SeveralIdeas by MartinCleaver)

DmozCatalogPlugin uses MySQL quite heavily, which contradicts a bit to TWikis general layout. Not using a database will probably have several advantages (performance?, complexity?) but since I have to use one for this purpose, it's there and I'ld like to use it for other applications (I payed the price already).

  • putting user configurations, maybe passwords and other user related stuff in the database, so that these can be set up via forms. Most of my non-computer-related friends don't seem to understand what three spaces are, nor do they read anything which smells like a software manual. So they simply ignore their homepage and the possibility to customize twiki using it.
  • I would like to store topic metadata in the database and also collect usagestatistics on a per topic basis, also ratings, and other stuff. I have no fixed plans on this, just ideas yet.
  • lots of other ideas, no time wink more to come

  • I'd like to see a TWiki::Store::MySql -- MartinCleaver - 15 Nov 2001

I played around a bit with the CORBA support for perl (i haven't found anything perl specific which does a similliar job yet) and it seems to have an acceptable performance (approaching 1000 empty calls per second). So I thought about having a single manager (corba) server who keeps track of editing and database changes, so that as a result it would be possible to prerender pages (the %TEXT% portion) and also to cache database queries.

Using such a scheme, maybe not corba, I just don't know an alternative, could be quite interesting.

-- MichaelUtech - 14 Nov 2001

I've been thinking about the idea of writing a TWiki::Store::MicrosoftSqlServer or TWiki::Store::Oracle - has anyone looked into the feasibility of this?

-- MartinCleaver - 17 Nov 2001

There's a perl package that abstracts the DBMS used (don't remember it's name, sorry). That seems to be usable, so we should probably consider to use that inspite of writing several different Store::DBs.

Once the api has settled, i don't think it's very complicated to write a DB module, but I'm not sure if there's a great benefit from using a DB as topic storage.

What is the current status of this package?

-- MichaelUtech - 23 Nov 2001

Abstract DBMS module: Do you mean excellent DBI.pm? Yes, you can use just standard SQL and code will be DBMS-independent. It will connect to correct DBD::whatever. Still, Data Definition Language (DDL)differs and needs to be customized to create tables in different DBMS. Or do you mean some fancy wrappers, like DBIx::Recordset or such?

-- PeterMasiar - 18 Dec 2001

Changes we made to this area, such that we now have separate modules/drivers for access to RCS and RcsLite. Given the progress of time I've moved the TopicClassification from FeatureUnderConstruction to FeatureBrainstorming.

-- JohnTalintyre - 30 Sep 2003

Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r10 - 2003-09-30 - JohnTalintyre
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.