-------------------------------------------------------------------------------------------
Dia 1 - 22/03/2004
Reunião dos Students Volunteers as 7:30
Como tinha de estar na sala do workshop as 8:30, pois eu era o estudante responsavel pelo
mesmo, não deu tempo de tomar café... ;-)
-------------------------------------------------------------------------------------------
8:45 Inicia o workshop [[http://trese.cs.utwente.nl/workshops/early-aspects-2004/][Early Aspects]] (vide o programa)
seguem anotações que eu fiz sobre as apresentações
-----------------------------
Finding Aspects in Requirements with Theme/Doc
E. Baniassad, S. Clarke
uma ferramenta de analise lexica para identificar candidate (crosscutting?) concerns, a
partir do documento de requisitos.
-----------------------------
Integrating the NFR framework in a RE model
I.Brito, A. Moreira
parece um trabalho bem relacionado com o de Georgia.usa NFR para definir crosscutting concerns
-----------------------------
Tracing aspects in goal driven requirements of process control systems
I. El-Maddah, T. Maibaum
Esse trabalho usa um exemplo de product lines que pode ser do interesse de Vander
é uma ferramenta
-----------------------------
Generating Aspect-Oriented Agent Architectures
U. Kulezsa, A. Garcia, C. Lucena
Geracao de aspectos para agentes. conferir se existem exemplos de product lines!
-----------------------------
Identifying Aspects Using Architectural Reasoning
L. Bass, M. Klein & L. Northrop (CMU)
identificar uma arquitetura de software a partir dos requisitos de qualidade.
baseado em architectural tatics -> meios de satisfazer uma medida de atributos de qualidade ...
definem join points, advices, aspects... no nivel de projeto (architectural join point...)
-----------------------------
Discussion Session I - Key Problems and Motivations
Requirements Engineering
- what is an aspect?
- what is crosscutting?
- do concerns lead to requirements?
Software Architecture Design
- quality concerns
- decomposition
- functional concerns
- achitectural evolution
- specification
- architectural knowledge
- architectural views
- composition (is architectural weaving possible?)
- evaluation
- bridge -> problem vs solution
PROBLEM: Aspects cannot be modularized in current architectural views
MOTIVATION: To increase/support evolution of the architecture(s)
EXAMPLE: Aspects like monitoring in EAS are scattered over the other views
PROBLEM: Tracing architectural aspects to subsequent phases
MOTIVATION: Architectural (crosscutting) concerns may not be maped to aspects in subsequent phases...
EXAMPLE:
PROBLEM: No tool support for architectural aspects
MOTIVATION: Need for automated support
EXAMPLE:
Domain Engineering/Application Domain
- domain engineering is concerned with PROBLEM UNDESTANDING
domain engineer
- ...
PROBLEM: Effective domain engineering is a prerequisite for effective requirements elicitation
MOTIVATION: Domain properties tends to be all encompassing, overlaping, widely spread, iteracting,
crosscutting
EXAMPLE: Quality Assurance
Specifying Early Aspects
- Where's crosscutting?
- crosscutting behavior
- overlap concepts sharing
- attributes
- properties
- constraints
- What are aspects?
- Concern Specification
/ ||
|| extraction
||
- Requirements Analysis
||
|| impact analysis
||
\/
- Architecure Design
- Impact Analysis
- crosscutting
- resolve conflicts
PROBLEM: What questions does aspect specification address?
can we give guidance about the aspects?
MOTIVATION:
EXAMPLE:
PROBLEM: Aspect specification in the life cicle
how does aspect specification aply across the early (and later) life cicle?
how do we capture this information?
relationships to artifacts
Early Aspects in initial development versus Early Aspects post development
-----------------------------
14:00
Discussion Session II - Promising Solutions
and
Discussion Session III - Setting the Research Ag
Requirements Engineering
- open problems:
what would be the ideal definition/representation
decomposition of concerns
completeness
how to identify appropriate representations
how to compose crosscutting concerns
how to solve conflicts when composing
how to represent specific kinds of subject matter:
is there a secialization needed?
Software Architecture Design
- in architecure design you are not forced to model the concerns in one model; like in code
- so in fact, the aspects are partially separated already
- there are already models for e.g. quality concerns such as security, performance, etc.
Domain Engineering/Application Domain
- goals of Domain Engineering (DE)
- develop software components/artifacts as close to code as possible
- challenges of DE
- concretness of components
????
- identify common concerns
- lots of concerns are implicit
- lots of concerns are recurring
- some concerns are know to interact
- identify relations between concerns and development artifacts
- which artifacts can handle common concerns
- are they separable?
- identify interation patterns between artifact and how they mat to concern
- it has to be a sequence of composing the concerns/aspects?
A composed to B = B composed to A?
A = log
B = tracing
Specifying Early Aspects
- solutions areas
- textual analysis
- tools for querying, visualization
- tools to analyze models for significant relationships and properties
- impact
- aspects
- analysis of compositions and extractions
- ...
- open problems
- solutions to specifying significance or impact of relationships
- how to help and guide users?
-------------------------------------------------------------------------------------------
20:30 - Eclipse BoF
Eclipse 3.0 diferencas/novidades
- permite o uso de Swing/SWT (requer jdk1.5)
- pode-se simplificar o uso do eclipse configurando-o a partir da pespectiva do tipo
de desenvolvedor
- desenvolvedor java
- web designer
- dynamic plug-in -> não necessita restart apos instalar ou desistalar um plug-in
- pode-se definir participantes que são avisados quando alguma atividade é executada,
como um refactoring, search... O participante por sua vez pode executar alguma ação
- general improvements: navigação, refactoring, code reading, edição...
- load-time weaving runtime
- let the Eclipse runtime weave the code considering the plug-ins installed/enabled
- next step
- "runtime-like-weaving"
- new views to expose global effects of crosscutting
- links de advices para codigo java e vice-versa na documentação Javadoc
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
Dia 2 - 23/03/2004
7:45 -> Registration Desk (trabalhando como Student Volunteer)
-----------------------------
14:00 -> Tutorial 4 - Good AOP: Idioms, Rules and Patterns in AspectJ
Adrian Colyer
Wes Isberg
Eu peguei uma copia do material (muito estranho por sinal)
Os slides deverão ser colocados no site da conferência e/ou nos do Wes Isberg!
- ??
- Rule: Keep advice short.
- Target Interface for type tagging
- Use an interface to identify types of interest
- Reusable AOP
- Alguns dos padroes implementados pelo Jan
- Modules/components/classes must be open to extend but close to change
- Clients should only see the interface they use (information hiding)
- Um aspecto legal é o de Profiling, ele pode nos mostrar gargalos no programa ou se uma
otimização é de fato uma otimização
-
Achei o tutorial um pouco fraco...
O Uirá achou MUITO fraco...
Foi um pouco confuso, era mais um BoF que um tutorial, dando dicas, exemplos de como implementar
usando AspectJ (vide as anotações acima em ingles) Repetiram várias informações de vários artigos...
por sinal depois eu passo essas referencias, podem ter algumas (varias) que nos interessem!
-----------------------------
18:30 -> Student Extravaganza
Apresentação do Poster
Bem, eu conseguir explicar o trabalho para algumas pessoas interessantes como o Gregor Kiczales,
Jonathan Aldrich, Awais Rachid, Wes Isberg, and others, incluindo um ex colega de Paulo de Oxford
(nao me lembro do nome dele). Todos disseram que gostaram: "that's cool", they said! ;-)
Vander, tem um aluno de doutorado aqui de Lancaster (Neil) que disse que você andou falando com
ele sobre o seu trabalho e que vc pediu para usar uma especie de ferramenta dele. Ele disse que
vai entrar em contato com você para te passar a feramenta! Lembra de cobrar ele e dizer que eu
te disse isso! O cara é gente fina!
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
Dia 3 - 24/03/2004
-----------------------------
8:45 -> Inicio dos trabalhos técnicos apresentações dos chairs
total de participantes -> 214
70% dos participantes são da Europa e US, 1% da america do sul, eu e o Uirá ;-)
taxa de aceitação dos papers 17% (15/82)
-----------------------------
Key note speaker -> Daniel Sabbah, Vice President of IBM
Aspect Oriented Software Development
from Promise
to Reality
- Desafios para a IBM e outros desenvolvedores em geral
- desenvolver vários produtos/mecanismos para diferentes partes do desenvolvimento
- banco de dados
- applications servers
- development process
- manter e testar diferentes tecnologias umas com as outras
- adaptabilizade
- flexibilidade
- ...idade
- "intuitivamente" AOSD ajuda!
- 75 pesquisadores da IBM trabalhando com AOSD nos labs. da IBM pelo mundo
- toronto, china, US, UK
- Investimentos da IBM
- Aspectj
- AJDT
- CME (cross-artefact, cross life-cycle capability) <- coisa nova!
- All are Eclipse based (open source)
- Enhancing the quality and serviceability of software
- adding diagnostic support into large software stack (a WebSphere component - WSIF)
- 17.000 lines of code
- using AspectJ!
- WSIF
- Re-Use and Product Line Implications
- Apache -> WSIF for open source
- WebSphere -> WSIF
- Technologies to enhance problem diagnosis adn serviceability
- HyperProbe:
- based on HyperJ
- Using aspects to analyze APIs (it seams to be an API scaner?)
- how spread and tangled they are?
- used with products under development
- WebSphere Portal
- WebSphere Commerce
- Tivoli products
- goal: identify use of private APIs by products that run on topo of the WebSphere
Application Server
- result: more than 50.000 violations found
- Enable the use of AO in new unified-ibm products
- Reengineering software
- WebSphere ...
- Allow sharing a portfolio of components between different IBM products
- "AOSD/AspectJ will be legacy code latter"!
- CME -> Concern Manipulation Environment
- "Aspects will be available in IBM products in the next months"
- Integration with Rational Tools
Uma coisa boa foi perceber que uma grande empresa como a IBM está investindo na área...
-----------------------------
Resumo dos demos
Demo 1 -> An AspectJ-Enabled Eclipse Runtime Engine
- Load-time weaving for AspectJ 1.1
Demo 2 -> JQuery: Finding Your Way Through Tangled Code
- Exploration of information using browsers are tengled and scatered
- Multiple views of source code in a single browser
Demo 3 -> JAsCO & WSML
- New AO language
- Dynamic AOP
- Plug-in of Eclipse
Demo 4 -> CME : The Concern Manipulation Environment
- Suite of tools that support AOSD across the full software lifecycle
- Integrated to Eclipse
Demo 5 -> Compose*: Language-Independent Aspects in .NET
- Compositing tools for Composition filters
-
Demo 6 -> AspectJ Tools - New and Noteworthy
- novidades do novo AJDT
- debugger support
- eager parsing
- content assist
- new crosscutting strucutre views
Demo 7 -> aTrack: An Enterprise Bug Tracking System using AOP
- Transaction
- persistence
- ...
-----------------------------
Technical Session - Languages 1
Remote pointcut - A Language Construct for Distributed AOP
- identify joint points in a program on a remote host transparently, like RMI to OOP
- eles usam um exemplo de aspecto de teste, logo eles estao usando o pointcut remoto
para testes
- DJcutter -> distributed AOP language
- remote pointcut
- remote inter-type declaration
- extendem cflow para inlcluir joint points remotos
- nova construção -> host (joint points executando em um host)
- permite load-time weaving
- referencia o nosso artigo de oopsla
- JAC ja prove um ou todas as construções de DJcutter
- um cara perguntou pq eles nao dizem isso no artigo, na verdade o cara "botou
pra lascar"...
- outro cara tb botou quente dizendo que o trabalho é muito limitado para o escopo de
sistemas distribuidos (como alias o meu tb é!) ;-) Temos de deixar bem claro o escopo do
trabalho... como vc já mencionou, Paulo.
- CANDIDADO AO GENTE
Association Aspects
- instanciation: allow programmers to create aspects instances
- association: aspects instances remember associated objects
- define um novo designator (associated) para associar dinamicamente aspectos
associated(l,r)
- find an aspect instance (r) associates to an object l
associated(l,*)
- find all aspects instances associated to an object l
- COMO A APRESENTAÇÃO FOI FEITA POR UM JAPONES ;-) É MELHOR DA UMA OLHADA NO ARTIGO
PRA VER SE VALE COLOCAR NO GENTE
-----------------------------
Technical Session - Weaving
Advice Weaving in AspectJ
- explica como o weaver é implementado...
- how matches are made
- faz comparação de performance com XSLT do apache...
- existe uma diferenca de performance se certas condições de execução puderem ser
colocadas no pointcut de modo a não habilitá-lo, ao invés de colocar um if no advice!
- it is easy to write inefficient code in AspectJ
- it is also easy to write efficient code in AspectJ! ;-)
- NÃO SEI SE INTERESSA PRO GENTE
A Technique for Constructing Aspects Weavers Using a Program Transformation Engine
- Weaver para Object Pascal
- em direção de weavers independentes de liguagem
- supporte para migração de sistemas antigos...
- A apresentação do Jeff foi muito boa! Ele usou várias figuras durante a motivação,
mas acabou mostrando muito código... ele também apresentou um video mostrando o uso da
ferramenta ... arretado! Porque não se corre o risco do negócio falhar na hora da
apresentação
- ACHO QUE NÃO CABE PARA O GENTE
Morphing Aspects: Incomplete Woven Aspects and Continuous Weaving
- otimização da abordagens de weaving dos weavers -> ?????
- não avalia/executa unecessary joing points
- dynamic weaving
- uses introspection
- use AspectS/ Squeak
- COMO OS DEMAIS PAPERS ESSE TAMBÉM É MUITO BAIXO NIVEL (weaver) PRO GENTE ATUALMENTE
-----------------------------
Industry Panel: AOP for the Enterprise
Gregor Kiczales (UBC), Jonas Bonér (BEA Systems), Adrian Colyer (IBM), and Marc Fleury (JBOSS)
- Aspects esta sendo adotado muito rapidamente, se comprarado a adoção de Java, que era uma
linguagem nova, porem para um paradigma já existente, parecida com C++ ...
- EJB falhou!!!!?
- não há uma definição do que é exatamente orientação a aspectos. muitos podem passar a dizer
que programam orientado a aspectos sem o fazer... mas apenas pela fama de AOP! ;-) Como muitos
ja fizeram com OO
- O Kiczales disse que em 89 uma empresa que ele não recorda o nome ;-) dizia que porque
o seu software permitia mover icones em um desktop esse software era orientado a objetos
(microsoft?) ;-) ou seja, não há, eprovavelmente nunca haverá, uma definição exata sobre de
onde até onde vai AOP. Como hoje em diz pode não haver uma definição exata sobre OOP!
- Encorajar uma adoção progressiva (aos poucos) de aspectos na industria, principalmente para
os novatos na área... ao invés de partir direto para AOSD talvez usar debugging aspects...
parece que o pessoal no ipad está fazendo algo assim, usando apenas aspectos de desenvolvimento,
certo Boinha? Boinha assina essa lista? ;-)
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
Dia 4 - 25/03/2004
-----------------------------
Keynote
Crosscutting Requirements
Bashar Nuseibeh, Open University
- Orientation
- Eliciting concerns
- Modeling and Analysing concerns
- Communicating concerns
- Agreeing concerns
- Evolving concerns
- "Requisitos preenchem o espaço entre os objetivos do cliente e a implementação do código"
- What is requirement engineering
- a software architect?
- a systems engineering?
- an anthropologist?
- ...?
- Why is RE changing?
- Refinement - not realistic?
- Documentation - not necessary?
- Time scales - too long?
- The ViewPoints Framework (anos 90?)
- qual a diferenca entre viewpoint e use-case?
- o apresentador deu a entender que o framework de viewpoints é mais orientado a
aspectos que use-cases
-----------------------------
Technical section - Applications I
Large-scale AOSD for Middleware
- motivação
- unir vários produtos da IBM para gerar produtos/sistemas que vão de encontro as
necessidades específicas dos clientes
- adicionar EJB ao websphere (removendo outro suporte, imagino que com
funcionalidades de alguma forma similar ao EJB, o que o websphere tinha antes)
- websphere tem 15.000 arquivos fontes, mais de 240 modulos...
- usaram JQuery para achar lugares no código que usavam certos recursos. depois
faziam refactoring destes recursos para suportar EJB, em sequida rodavam outra query,
analisavam o resultado, faziam outro refactoring e assim por diante
- Refactoring
- first try to use OO refactoring
- only then use AO (AspectJ)
- try to disturb the codebase as little as possible
- Depois disso eles podem adicionar/remover supporte a EJB selecionando ou não os
aspectos que o fazem
- 74% de inter-type declarations: 26% advice
- each piece of advice affected only a single pointcut
- 92% of the inter-type declarations affected only a single target-type
(maximum was 6)
- OO vs AO refactoring
- object-based refactoring not always possible / more difficult / more invasive
- AO refactoring were often
- simpler
- less-invasive
- more agile, more pragmatic
- como identificar, analisar os tipos do sistema com as ferramentas do AJDT, como
o aspect visualizer
- AJDT vs JDT??? qual é mesmo a diferença?
- INTERESSANTE PARA ANALISAR COMO ELES USAM JQUERY E ASPECTJ PARA AJUDAR O
REFACTORING INFORMAL. DEFINITIVAMENTE DO INTERESSE DO GENTE.
Building Adaptive Distributed Applications with Middleware and Aspects
- middlewares como CORBA e RMI tornam transparentes para o programador a natureza da
distribuição e de QoS como fault tolerance, network bandwidth, available processor power,
security...
- por outro lado eles dificilmente podem ser especializados para necessidades específicas
dos clientes
- eles definiram o middleware usando aspectos onde a funcionalidade do middleware e QoS
estão separados...
- eles usa uma linguagem orientada a aspectos própria - ASL
- aparentemente com várias construções similares as de AspectJ
- parece ter algumas novas
- tem uma que define regiões...????
- por outro lado parece/é uma linguagem de dominio especifico
-
- PODE SER INTERESSANTE PARA O GENTE NO SENTIDO DE ENTENDER MELHOR AS NOVAS CONTRUÇÕES
DEFINIDAS PELA LINGUAGEM ASL. PODEM SER MAIS PODEROSAS QUE AS DE ASPECTJ
The COMQUAD Component Model - Enabling Dynamic Selection of Implementations by Weaving
Non-functional Aspects
- COMQUAD --- COMponents with QUantitative properties and ADaptativity
- non-functional properties
- specify those properties as crosscutting concerns using descriptors
- container performs Aspect Weaver at runtime
- negociation of contracts between components
- split container architecture
- me parece mais um artigo para customização de middleware ...
- usa uma maneira não conhecida (pelo menos por mim) de modelagem/especificação
(descriptors?)
- mas acabou mostrando um modelo equivalente em UML!!!
- trabalha mais em runtime do que em programming language level
- NÃO DEU PARA AVALIAR BEM PQ Q APRESENTAÇÃO DO CARA FOI UM POUCO ENROLADA
- GENTE?
-----------------------------
Technical section - Tools and Implementation
Virtual Machine Support for Dynamic Join Points
- types of crosscutting
- code-level crosscutting
- statically bound crosscutting
- unbound dynamic crosscutting
- as tecnicas atuais de weave fazem mudanças pre-runtime e invasivas que levam a
problemas como o de debugar um método não escrito por nós, mas inserido por algum weaver.
outros exemplos são performanace, profiling. OS WEAVERS NÃO PRESERVAM A ESTRUTURA
ESTÁTICA DOS PROGRAMAS
- eles propõe uma solução -> structure-preserving compilation (Caesar <- o nome do
produto deles!)
- aspects as first-class entities
- easier debbuging
- true separation compilation
- performance
- "late biding" of join points
- selective (de)activate join point shadows at runtime
- pragmatic deployment
- a linguagem não suporta o advice around
- eles modificam o bytecode inserindo ou removendo / (un)deploy an aspect "instance"
- na verdade eles geram uma cópia do bytecode e modificam essa cópia, premitindo
assim undeploy o aspecto se/quando necessário. O programador define os join points
nos quais devem ser deployed o(s) aspecto(s)
- VAI PRO GENTE OU NÃO VAI?
Untangling: A Slice Extraction Refactoring
- refactoring from OO to AO
- aspects would be (un)plugable
- eles tem um plug-in para eclipse (INOVATION GRANT support)
- ajuda a identificar partes do código que deveriam ser modularizadas e executa o
refactoring -> SLICING
- fez uma demonstração com um toy example
- programmers mentally construct slices when debugging [Weiser's]
- programmers mentally construct slices when untangling [the author]
- the plug-in has three approaches
- Procedural
- extract slices as methods
- extract method refactoring
- OO
- extract slices as objects
- extract method-object (ou object-method?) refactoring
- AO
- extract slices as aspects
- similar ao extract method-object refactoring so que gera um aspecto
- o plug-in é bem legal, e ele teve coragem de fazer demonstrações ao vivo! ;-)
- segundo o apresentador a ferramenta rejeita refactorings que não são
behavior-preserving -> STATIC ANALYSIS
- A GRANDE DIFERENÇA COM O QUE ESTAMOS FAZENDO OU IREMOS FAZER É QUE A FERRAMENTA NÃO
APENAS FAZ O REFACTORING, MAS ANTES DISSO AJUDA A IDENTIFICAR QUE PARTES DO PROGRAMA LIDAM
COM UM DETERMINADO CONCERN (MANIPULAÇÕES DE CADA ATRIBUTO DE UMA CLASSE, NO EXEMPLO DELES),
OU SEJA ELES FAZEM ALGUMA ANÁLISE ESTÁTICA DO PROGRAMA.
- That's indeed a paper to GENTE!
Josh: An Open AspectJ-like Language
- uma nova linguagem -> Josh
- users can define a new pointcut designator
- como uma especie de meta programming
- suporta dynamic join points
- NÃO SEI SE PODEMOS TALVEZ USAR ISSO PARA REESCREVER UM CFLOW REMOTO. VAI PRO GENTE? ;-)
-----------------------------
Industry Paper
Object-to-Aspect Refactorings For Feature Extraction
- An AOP (AspectJ) version of Fowler's book would be helpful
- Refactoring experiment
- aspect mining
- navigating the code, browsing, searching
- Writing unit tests
- o experimento foi refatorar uma feature de um sistema para aspectos que gerou alguns
refactorings
- extract pointcut
- extract advice
- ...
- DEFINITIVAMENTE CABE PARA O GENTE
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------
Dia 5 - 26/03/2004
-----------------------------
AOSD 2005 - Chicago (Mira)
AOSD 2006 - Bohn (Gunter)
AOSD 2007 - Vancouver and ?
AOSD 2008 - ?
Invited Industry Paper
What are the key issues for commercial AOP use - how does AspectWerkz address them?
- foco em entreprise AOP
- em AspectWerkz Aspect é uma superclasse que deve ser herdada para definir aspectos
do seu sistema...
- os advices são métodos Java que recebem como parâmetros join points (objetos Java)
- tem um arquivo de configuração em XML para definir propriedades
- AspectWerkz is a framework targeted towards dynamic aspect-oriented programming (AOP)
in commercial applications. Based on our experience designing and supporting AspectWerkz,
we have identified what we believe are key issues for the commercial adoption of AOP.
These are usability, agility, integration, expressiveness, performance, tool support and
the concept of an aspect container that manages issues like security, isolation, visibility,
deployment and manageability for the aspects. This invited talk will discuss these issues
and how AspectWerkz tries to address them.
-----------------------------
Technical section - Applications II
Deriving Security Requirements from Crosscutting Threat Descriptions
- falou muito sobre modelagem usando uma notação ?X? ...
- ACHO QUE NÃO É PARA O GENTE
Using AspectJ to Separate Concerns in Parallel Scientific Java Code
- Performance as an aspect
- o aspecto gera interleaving em certos pontos do programa (ex. loops)
- PODE SER INTERESSANTE PRO GENTE
-----------------------------
Technical section Languages II
- TIVE DE SAIR DEPOIS DO ALMOÇO
Hybrid Aspects for Weaving Object-Oriented Functionality and Rule-Based Knowledge
Composition, Reuse and Interaction Analysis of Stateful Aspects
-- SergioSoares - 16 Apr 2004
Edit | Attach | Print version | History: %REVISIONS% | Backlinks | Raw View | Raw edit | More topic actions
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding TWiki? Send feedback