{
    "info": {
        "author": "Andreas Jung",
        "author_email": "info@zopyx.com",
        "bugtrack_url": null,
        "classifiers": [
            "Programming Language :: Python"
        ],
        "description": "zopyx.versioning\n================\n\n``zopyx.versioning`` is a generic versioning system for schema-oriented\ncontent-objects (zope.schema, Archetypes, Dexterity etc.).\n\nWhy another versioning system?\n------------------------------\n\nExisting versioning approaches in the Zope world are:\n\nCMFEditions\n++++++++++++\n\n- widely used\n- very monolithic\n- too tight integration with CMF\n- fragile implementation\n- doing \"too much\"\n- doing \"too much\" in a very intransparent way\n- no backend serialization format other than Python pickles\n- only ZODB-based backend\n- backend not pluggable\n\nBasic concepts\n--------------\n\n- golden rule #1: keep it simple, keep it small\n\n- pluggable storage API (storing the versioned data)\n\n- using JSON as data exchange format between objects to be versioned \n  and versioner and between versioner and backend storage (the storage\n  may use a different serialization format (e.g. 'pickle' for a ZODB\n  based backend or 'json' for a typical noSQL backend like MongoDB)\n\n- making use of the Zope Component Architecture for adopting arbitrary \n  content objects to the storage API\n\n- the solution does not claim to store and restore the complete state of\n  an content object. Instead we focus on dealing with the metadata and\n  the content itself. If an object uses a complex internal data model then it\n  is in responsible to serialize and deserialize the data to JSON.\n\n- leave complex functionality (likely handling of references, object relations\n  etc.) out of the core versioning engine - this might be handled through\n  adapters implementing IVersionSupport.\n\n\nOpen points\n-----------\n\n- should de-duplication be handled on the storage layer or the versioning layer\n  (I assume on the storage layer as an optional feature in order to keep the\n  overall complexity low)\n\n- all versionable objects must provide a unique ID (``UID`` for\n  Archetypes-backed content). How about Dexterity? How about\n  ZTK/zope.schema-based content?\n\n- how deal with \"large\" content. E.g. a MongoDB-based backend has by default\n  a 4MB limit for embedded documents (usually enough for standard content but\n  not for binary content like images)   \n\nAuthor\n------\n\n| ZOPYX Ltd.\n| c/o Andreas Jung\n| Charlottenstr. 37/1\n| D-72070 Tuebingen\n| Germany\n| info@zopyx.com\n| www.zopyx.com\n\nChangelog\n=========\n\n0.1.0 (2010-07-09)\n-------------------\n\n- Initial release with MongoDB-based version storage",
        "description_content_type": null,
        "docs_url": null,
        "download_url": "UNKNOWN",
        "downloads": {
            "last_day": -1,
            "last_month": -1,
            "last_week": -1
        },
        "home_page": "http://svn.plone.org/svn/collective/",
        "keywords": "",
        "license": "ZPL",
        "maintainer": null,
        "maintainer_email": null,
        "name": "zopyx.versioning",
        "package_url": "https://pypi.org/project/zopyx.versioning/",
        "platform": "UNKNOWN",
        "project_url": "https://pypi.org/project/zopyx.versioning/",
        "project_urls": {
            "Download": "UNKNOWN",
            "Homepage": "http://svn.plone.org/svn/collective/"
        },
        "release_url": "https://pypi.org/project/zopyx.versioning/0.1.0/",
        "requires_dist": null,
        "requires_python": null,
        "summary": "A flexible and pluggable versioning system for schema-oriented documents",
        "version": "0.1.0"
    },
    "last_serial": 185928,
    "releases": {
        "0.1.0": []
    },
    "urls": []
}