Search: concept

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

. == 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?

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.

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?

XWiki Help Desk Data Model Proposal of a preliminary data model/ The terms "Issue" and "IssueLog" are used preferably to "Question" and "Answer" since the help desk concepts are very close to the ones of an issue tracker, and using a common data model for both may be handy.

= XWiki Help Desk Data Model = Proposal of a preliminary data model/ The terms "Issue" and "IssueLog" are used preferably to "Question" and "Answer" since the help desk concepts are very close to the ones of an issue tracker, and using a common data model for both may be handy.

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

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 ??

Design explorations: common widgets/features(UI wireframe) [100%]http://enterprise.xwiki.org/xwiki/bin/view/Main/Features MILESTONE 1: Clear concept of what is to be coded/written http://extensions.xwiki.org/xwiki/bin/view/Main/WebHome#|t=extensions&p=1&l=30&s=doc.creationDate&d=desc&name=app Week 3 [4 June - 8 June].

Design explorations: common widgets/features(UI wireframe) [100%][[http://enterprise.xwiki.org/xwiki/bin/view/Main/Features]] **MILESTONE 1: Clear concept of what is to be coded/written** [[http://extensions.xwiki.org/xwiki/bin/view/Main/WebHome#|t=extensions&p=1&l=30&s=doc.creationDate&d=desc&name=app]] Week 3 [4 June - 8 June].

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.

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