Search: concept

. */ Iterator<Patch> getUpdatesFrom(PatchId from) Iterator<Patch> getAllPatches() /** This method is inclusive: from and to patches are included */ Iterator<Patch> getDelta(PatchId fromPatch, PatchId toPatch) /** do we need to introduce a concept of dependencies between patches? */ Iterator<Patch> getDependencies(PatchId) /** a patch can be signed using a key, that is registered beforehand to the service: * see the registerKey method.

Solution n°1 : Richer HTML (not used) This concept is to replace (in a lazy way) initial HTML by a richer HTML.

So, a new strategy, based on targeting content instead of documents is described by the following: a way to provide a reference to a field in an object in a document will be devised (for example, expanding the DocumentName concept) Annotation model changes to store such a reference to a field (or to the document itself in which case it means 'document content') annotation API changes as follows: where the renderAnnotatedContent can be replaced, in case of a HTML only based approach (as in the above solution), by a or syntax could default to XHTML, etc. on the client, when using the annotations one would need to mark the source (object field, document content, etc) of a piece of XHTML and the fact that it can be annotated.

=== ==== Solution n°1 : Richer HTML (not used) ==== This concept is to replace (in a lazy way) initial HTML by a richer HTML.

So, a new strategy, based on targeting content instead of documents is described by the following: * a way to provide a reference to a field in an object in a document will be devised (for example, expanding the DocumentName concept) * Annotation model changes to store such a reference to a field (or to the document itself in which case it means 'document content') * annotation API changes as follows: {{code}}void addAnnotation(String reference, Annotation ann) String renderAnnotatedContent(String reference, Set<Annotation>, String syntax) Set<Annotation> getAnnotations(String reference){{/code}} where the renderAnnotatedContent can be replaced, in case of a HTML only based approach (as in the above solution), by a {{code}}String getAnnotatedHTML(String reference, Set<Annotation> annotations){{/code}} or syntax could default to XHTML, etc

It is generally based on the old cache services concepts even all the names changes but the more I'm working with JBoss cache the more I think this api need some changes as JBoss cache and OSCache has very different way to create there caches.

I'm thinking of introduce eviction algorithms concept like JBoss or cache4j do to replace the way restriction like capacity and timing are supported.

It is generally based on the old cache services concepts even all the names changes but the more I'm working with JBoss cache the more I think this api need some changes as JBoss cache and OSCache has very different way to create there caches. === Cache configuration overwriting === Code creating a cache can declare an cache configuration identifier which is used to try to find a configuration in a file for example depends on the cache implementation to overload the default settings cache by cache.

I'm thinking of introduce eviction algorithms concept like JBoss or cache4j do to replace the way restriction like capacity and timing are supported. == TODO == === Meta cache === for documents cache, Ludovic proposed the idea of something like a "meta cache" when we are using distributed cache: the idea is to only store the documents version in the distributed cache and store the reall document in a local cache.

. == Proposal == {{html clean="false" wiki="true"}} * Component-oriented architecture using a Component Manager * Each component group (set of components for implementing a concept) is separated in its own build module and generates a JAR * Make the component 100% independent of the Component Manager used * Register the Component Manager using a Servlet Context Listener * Question: Should we use existing components from the Component Manager implementation?

[Pluggable security model that can maintain ACL at object level>http://whiteboardjunkie.wordpress.com/2008/11/24/where-am-i-using-jcr-and-why/] JSR 283 (JCR 2.0) further introduces the concept of shareable nodes which allows multiple paths of access to a node, providing the ability to implement faceted navigations through content JSR 283 further introduces the concept of journaled listeners which can ask the repository to re-play all events after a certain timestamp Shareable nodes.

JSR283 hence introduces the (optional) concept of shareable nodes. This allows implementing multiple URIs for a given model object.

Mapping: Wiki = Workspace We cannot have Wiki = Repository since there's no inter repository operations and we want for example the ability for a given wiki to include a document from another wiki Allows clone nodes between wikis and support references between wikis (children wiki can have references to admin wiki documents for example) UUID are unique per repository (and not per workspace) A node with the same UUID in several workspaces point to the same Node Note: one version storage per repository Ability to call Node.update(String srcWorkspace) to replace this node by the one and its children from the srcWorkspace (same as svn update) We can still have the ability to clone a wiki (and thus clone a workspace) to provide a working branch (for example for staging a workspace) and then later on do an update (as in svn update) to merge the changes back into the main "trunk" Document = Node + special NodeType Document metadata = Property Space = Node + special NodeType Document objects = Node + special NodeType (subnode of Document) Document object properties = Propery Document classes = Node + special NodeType (subnode of Document) Document class property = Property Attachment = Node + special NodeType (subnode of Document) Attachment data/metadata = Property Advantages of using JCR: Standardized Existing implementations (JackRabbit, exo JCR, etc) Ability to use existing tools that act on JCR: JCR Explorer Idea: Use workspaces to provide editorial workflow: At the core of the specification is the concept of the repository. A repository contains any number of workspaces.

. ** [Pluggable security model that can maintain ACL at object level>http://whiteboardjunkie.wordpress.com/2008/11/24/where-am-i-using-jcr-and-why/] * JSR 283 (JCR 2.0) further introduces the concept of shareable nodes which allows multiple paths of access to a node, providing the ability to implement faceted navigations through content * JSR 283 further introduces the concept of journaled listeners which can ask the repository to re-play all events after a certain timestamp * Shareable nodes.((( > In JSR170, a node can only be the child node of one other node.

JSR283 hence introduces the (optional) concept of shareable nodes. This allows implementing multiple URIs for a given model object. ))) * "Primary child item" feature.

* Mapping: ** Wiki = Workspace *** We cannot have Wiki = Repository since there's no inter repository operations and we want for example the ability for a given wiki to include a document from another wiki *** Allows clone nodes between wikis and support references between wikis (children wiki can have references to admin wiki documents for example) *** UUID are unique per repository (and not per workspace) *** A node with the same UUID in several workspaces point to the same Node *** Note: one version storage per repository *** Ability to call Node.update(String srcWorkspace) to replace this node by the one and its children from the srcWorkspace (same as svn update) *** We can still have the ability to clone a wiki (and thus clone a workspace) to provide a working branch (for example for staging a workspace) and then later on do an update (as in svn update) to merge the changes back into the main "trunk" ** Document = Node + special NodeType ** Document metadata = Property ** Space = Node + special NodeType ** Document objects = Node + special NodeType (subnode of Document) ** Document object properties = Propery ** Document classes = Node + special NodeType (subnode of Document) ** Document class property = Property ** Attachment = Node + special NodeType (subnode of Document) ** Attachment data/metadata = Property * Advantages of using JCR: ** Standardized ** Existing implementations (JackRabbit, exo JCR, etc) ** Ability to use existing tools that act on JCR: *** [[JCR Explorer>>http://www.jcr-explorer.org/screenshots.html]] * Idea: Use workspaces to provide editorial workflow:((( > At the core of the specification is the concept of the repository. A repository contains any number of workspaces.

In order to do so, here is a list of criteria that we need to take into account : * Ease of use : the new layout of the editor needs to be easy to use for newcomes and people lowly familiar with the concept of a wiki ** Speed : how long it takes for an user to perform an action (from basic to complex ones) ** Feeling of control : whether or not the user feels like he is in control of his environment and the software-model matches the user-model of how a rich text editor should behave * Flexibility : XWiki is an extensible platform, therefore the editor look & feel needs to make sure that we can add new components easily when needed ** Add new menu options when new features are created (say, new macros) ** Allow for minimal customization of the menus as required for specific projects (say, a "my favorite buttons" toolbar) ** Offers a light mode that includes needed features while in form textarea edition (comments, description fields, basically any textarea field in the wiki) * Development Issues : we need to take into account the fact that we are or are not able to reuse existing components for the editor.

Note: could reuse the "Types" concept here maybe, with a built-in type "SPAM" that would automatically check some keywords against subject/body content ??

Note: could reuse the "Types" concept here maybe, with a built-in type "SPAM" that would automatically check some keywords against subject/body content ??

I wonder if we cannot somehow merge the concepts together. I guess I'd need to see some examples for this.

Users have the possibility to enhance the public graphs locally by adding concepts and relations that make sense to them, involving local desktop resources, for the purpose of learning and memorizing.

It is also based on a view concept for the tailoring of ontologies. This view concept turned out to be of additional value, as it also provides a mechanism to impose different semantics on the same syntactical structure.

Users have the possibility to enhance the public graphs locally by adding concepts and relations that make sense to them, involving local desktop resources, for the purpose of learning and memorizing.

It is also based on a view concept for the tailoring of ontologies. This view concept turned out to be of additional value, as it also provides a mechanism to impose different semantics on the same syntactical structure. * SKOS http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20050510/ == Proposal == (% style="list-style-type: square" %) * Create a new JIRA project for describing use cases, tasks, requirements * Describe further the use cases * Create a first application implementation * Link the implementation with the PSEW prototype === Data model === See [[Design.HelpDeskDataModel]] == Other help desk systems == See [[Design.HelpDeskWatch]] == Roadmap == (% style="list-style-type: square" %) * 30 September 2007: release of a first implementation of the help desk * 15 October 2007: release of a report assessing the prototype from the user point of view * 30 October 2007: release of the second implementation, and presentation of the system at the [[eChallenges Conference>>http://www.echallenges.org/e2007/default.asp?

Cryptographic reminder If you are fluent with cryptographic terms, go ahead to the next section, but if you are not so sure, here is a very quick reminder of important cryptographic concept used in this proposal. Private keys, Public keys and Passphrases To encrypt data, a mathematical formulae (a Cypher) is used and base its algorithm on some secrets.

To achieve those goals, the implementation will separate the following concepts as much as possible: Integrity checks: process of checking a signature, and extracting the certificate used to sign Authorship attribution: process of associating certificate with users or organisation, and constitution of a web of trust Authorization: process of attributing enhanced privilege to a piece of code that have passed the integrity check and that have been signed by a given certificate Execution : process of controlling the execution of the code based on its authorizations Implementation Cryptographic signature Since the crypto API has been built with the idea to apply it to signed script, and moreover it is heavily based on widely used standards (x509 certificate and PKCS#7 signatures), it is probably our best choice to provide all the machinery needed to sign and check signatures.

= Cryptographic reminder = If you are fluent with cryptographic terms, go ahead to the next section, but if you are not so sure, here is a very quick reminder of important cryptographic concept used in this proposal. == Private keys, Public keys and Passphrases == To encrypt data, a mathematical formulae (a Cypher) is used and base its algorithm on some secrets.

To achieve those goals, the implementation will separate the following concepts as much as possible: * Integrity checks: process of checking a signature, and extracting the certificate used to sign * Authorship attribution: process of associating certificate with users or organisation, and constitution of a web of trust * Authorization: process of attributing enhanced privilege to a piece of code that have passed the integrity check and that have been signed by a given certificate * Execution : process of controlling the execution of the code based on its authorizations = Implementation = == Cryptographic signature == Since the crypto API has been built with the idea to apply it to signed script, and moreover it is heavily based on widely used standards (x509 certificate and PKCS#7 signatures), it is probably our best choice to provide all the machinery needed to sign and check signatures.