Show last authors
1
2 The XClams velocity apis are [available in similar format as JavaDoc>Design.CurrikiVelocityAPIs].
3
4 The working draft of the [Curriki REST API>RestApiDocumentation.WebHome] is also available.
5
6 1.1 Description
7
8 In curriki there are three levels of APIs that will be used:
9 * Plugins
10 ** These provide access via the xwiki object ($xwiki.pluginname in velocity)
11 * Custom Classes
12 ** These provide specialized classes for documents (pages) and possibly (to be tested) objects
13 * Servlets
14 ** These provide external access points to be used by other applications (including Javascript AJAX calls)
15
16 1.1 Direction
17
18 The initial focus will be to provide only the functionality required to complete the EOU 1 phase of development.
19
20 * A servlet will be needed to provide the needed wrappers for the internal APIs (currently targeting Add Path functionality only) that are needed for AJAX and other external applications
21 ** [Asset Servlet Requirements>Design.AssetServletRequirements]
22 * A plugin (AssetManager) will be needed to provide general access to functions that are not directly related to a page (such as creating an asset)
23 * A custom class (org.curriki.xwiki.plugin.asset.Asset) will be needed to provide asset level functions, which should probably use object level custom classes for the various types of assets
24
25 1.1 Decisions
26 * The Asset servlet should be used instead of using wiki pages to provide the functionality of editing and updating asset metadata and rights.
27 * The Asset Servlet should provide a REST-style API for both Java script interfaces in the application and as a generalized web services interface to transact with resources in the repository. The interfaces should be extended over time to meet this objective.
28 * Discussions with partner are commencing to define the syntax and parameters for this generalized we service API. This will be extended from the JSON interfaces created in V1.6 for the Add path.
29
30
31 1.1 Proposed Use Cases with Partners
32
33 * Partner Member to submit content that would also be added (shared) with Curriki and perhaps other repositories.
34 * Partner Member can search for content on Curriki while on partner site
35 * Partner Member links to (embeds a copy of) content
36 * Partner Member copies content to partner site
37 * Curriki (and Partner?) Member can delete their content while on partner site
38 * Curriki (and Partner?) Member can create content on Curriki and push it to partner site
39
40 _Please define "Member" in this context._ Curriki Member, or Partner Member?
41
42 _Feel free to correct my attempt at defining Curriki vs Partner Members_
43
44 1.1 Proposed Extensions to Support Partners
45
46 * Single Sign On
47 ** Requires
48 **# Distributed Identity Management/Authentication
49 **# Authorization
50 ** Possible services used
51 **# Local
52 **# OpenID
53 **# OpenSSO
54 **# SAML
55 **# Shibboleth
56 **# WS-Federation
57 **# PAPI
58 **# CAS
59 * Copy resource
60 ** Is this like export ?
61 * Link to resource
62 ** In what regard? The page name is already a "link".
63 *** I think of a resource link more as embedding (via SWF or javascript code) like a YouTube video or a Delicous.com Tagcloud. The original resource is always hosted by curriki, but can be displayed on partner sites.
64 * Get a Resource
65 ** What type of format?
66 ** Can you clarify between copy & get?
67 * Post a Resource from a partner site
68 ** Can be done now with add path. What is different here?
69 * Delete a Resource from a partner site
70 * Search resources from a partner site
71 ** Is this different than the new search?
72 *** Search via an API so that partner sites can create a tool that searches curriki content.
73
74
75 1.1 Meeting Notes
76
77 * [API Extension to Support Partners Sept-03-2008>PartnermtgSept032008]
78
79
80
81
82
83
This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 12.10.5-node2 - Documentation