Feature Proposal: Make Meta a first class Public API

Motivation

as of foswiki 1.1, we say 'in general you should call the Foswiki::Func methods in preference to calling Foswiki::Meta '

This is a tad frustrating, once you have a Meta object, you have to use some of its methods, but are requested to scan Func for the possibility that there might be a Func version.

Description and Documentation

The Func API doesn't need to be changed - just the implementation of the relevant portions moved into Meta fully, and Meta cleaned of any remaining legacy Filesystem idioms.

I'd like to move 'getEmbedded*' into Foswiki::Serialise.

The long term goal is to make the TopicObject be the primary interface to that all of foswiki uses to get information from the Store backend, and we are so close to this ideal, that its time to finish it off.

(I would like to be able to subclass Meta to leverage benefits from other backends, but we need to talk about that a little.)

Another thing that we'd like to try, is to make some effort to ensure users don't break the encapsulation, and talk directly to the Store modules - all requests to the store should go via Meta anyway (tightening up security)

This will give us some improvements in the core too, as methods like Foswiki::webExists() currently makes a request directly to the Store, preventing us from making use of already cached information (as in the Foswiki::MetaCache).

Related: QueryAcrossTopicRevisions, AddAReadOnlyMetaClass, SimplifyTheStoreMetaSemantics

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: SvenDowideit - 14 Nov 2010

Discussion

A simple first step would be to clean up the documentation for Foswiki::Meta and allow for three types of interface:

1. Truly public methods
2. Truly private methods
3. Methods that are intended for use by the core (and are therefore subject to change), but are not part of the formal interface.

For now, we should exclude anything "bad" or "ugly", and put only "good" things into the formal, public API. Bad and ugly interfaces may then be refactored and make public incrementally.

-- MichaelTempest - 14 Nov 2010

One reason I didn't change the name of this class is that I don't like the interface. This is because a number of key methods - get, put etc - rely on exposing the internals of the object in a way that I find unacceptable. Because Meta was already widely used in external code when I started touching it, adding getter setters was never an option. So, here's my preferred route:

1. Deprecate (but maintain as-is) the Foswiki::Meta class.
2. Define a new (better) interface (that can be implemented by Foswiki::Meta) that has the good, but not the bad or the ugly.
3. Make the new interface the public API (and serve it from Sven's desired independent factory)

However you should note that the big problems are not so much with the interface, as with the poorly understood semantics.

-- CrawfordCurrie - 15 Nov 2010

My MongoDBPlugin work with PaulHarvey has lead me back to generalizing the Foswiki::MetaCache into a way to reduce the number of times foswiki hist the datastore.

I began implementation using the tools we have in trunk - the Existing single session, SEARCH MetaCache and the newer Store::Listener::loadTopic interface, but I keep falling over the legacy that is how we are forced to pass addresses, create and load Meta objects, and the maddening complexity that Foswiki::Store appears to be.

Thus, I'm beginning to try to write up a SimplifyTheStoreMetaSemantics proposal - which (at least initially) will try create a new API set for talking about, passing around and manipulating stored items - with the intent to deprecate the older methods without breaking them.

-- SvenDowideit - 13 Feb 2011

Developer is no longer contributing. Changed status to 'ParkedProposal'

-- Main.CrawfordCurrie - 11 Jan 2016 - 18:00