-
Notifications
You must be signed in to change notification settings - Fork 51
/
proposals.apt
44 lines (35 loc) · 1.96 KB
/
proposals.apt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
~~
~~ Copyright 2010 OpenEngSB Division, Vienna University of Technology
~~
~~ Licensed under the Apache License, Version 2.0 (the "License");
~~ you may not use this file except in compliance with the License.
~~ You may obtain a copy of the License at
~~
~~ http://www.apache.org/licenses/LICENSE-2.0
~~
~~ Unless required by applicable law or agreed to in writing, software
~~ distributed under the License is distributed on an "AS IS" BASIS,
~~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
~~ See the License for the specific language governing permissions and
~~ limitations under the License.
~~
Proposals
A main directive of OpenEngSB is its continuous extension. Most ideas are discussed
in the mailinglist first, but at some point a more consistent way of specification is required.
For the OpenEngSB project this should be done via written proposals in the proposals
section. This article explains in more details what this means and how it should be handled.
*General
First of all some general information about proposals; Please write them, as everything else
on this page in English! Further write all proposals in APT and add them to the
/engsb-docs/src/site/apt/proposals folder. The structure itself could be chosen by the type of
the document.
*Domain Description
This section describes what should be contained in the proposal for an interface description.
The structure of the documents themselves should be done in the following form:
[[1]] Which tools exist for the domain
[[2]] What does these tools can, what is the common sense between these tools
[[3]] What services are required for the domain to use the services available. This should be done in
"the java way of live". Simply define an interface and document it and its data types in most
detail.
[[4]] Define which events could be thrown by the domain. Define java classes and describe in detail
when this event should be thrown.