diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000..9703f44 --- /dev/null +++ b/.gitattributes @@ -0,0 +1 @@ +*.org text working-tree-encoding=UTF-16 \ No newline at end of file diff --git a/README.org b/README.org index 949da38..8dae659 100644 --- a/README.org +++ b/README.org @@ -1,4 +1,4 @@ -#+title: Repository to hold the pages for vlabs dev +#+title: README #+SETUPFILE: ./org-templates/level-0.org * Making changes @@ -10,5 +10,15 @@ Never make changes in the =master= branch. +* Testing your changes + +1. Do not change the links to the style files in the sources! + +2. Build your sources + +3. Launch the local python server + +4. Point your browser to =localhost:8000= + diff --git a/src/labs/hosting.org b/src/labs/hosting.org index 185757d..d1e50c8 100644 Binary files a/src/labs/hosting.org and b/src/labs/hosting.org differ diff --git a/src/labs/review-log.org b/src/labs/review-log.org new file mode 100644 index 0000000..fd35ff1 --- /dev/null +++ b/src/labs/review-log.org @@ -0,0 +1,75 @@ +#+TITLE: Review of hosting process +#+AUTHOR: VLEAD +#+DATE: [2020-04-21 Tue] +#+SETUPFILE: ./org-templates/level-0.org +#+TAGS: boilerplate(b) +#+EXCLUDE_TAGS: boilerplate +#+OPTIONS: ^:nil + +* Introduction +This documents contains the comments from the review of the +[[./hosting.org][hosting process]]. + +* Review Comments + + +1. General comment :: How about we write in present tense. +2. Section =How does one become part of the virtual labs + community?= :: Probably the developers become part of the + community by registering and adhering to the process + maintained at IIT Bombay. And this community builds the + applications by following the defined process. +3. The section =Approvals= seems ambiguous. Hosting does + not obtain an quality check report, but will it be + presented by the owner as part of the registration + process. +4. Owner Registration :: A team of developers work on + repository. Does our process restrict one github + handle as the =Owner= to request hosting of built + application from these sources? Or do we allow multiple + handles to register as =Owners= for a single repo. + Also, does it mean an owner is registered first before + any application is registered. In similar vein, if the + application is registered with the owner details, do we + need a separate registration for owner. +5. In the table under the section - =Registration Workflow=, + should the process not allow the owner to resubmit a + failed registration request. +6. In the section =Identity of the application=, we should + mention that the issue id becomes the application id. I + added couple of lines to the file to make this explicit. + +7. From point 9 of the section =Hosting Workflow=, looks + like the hosting team re-hosts the same tag. Is the + assumption that re-hosting will solve the problem? A + scenario could be that the development team finds a bug + in the sources for the unexpected behaviour of the + application, and therefore could request a new tag to be + hosted or meanwhile could ask for a revert to the last + stable deployment. This could obviate the need for a new + request as stated in point 10. +8. Is there a transition from failed state. Can the request + be rectified and therefore change the state to Open + rather then closed state as stated in step 5 of table. +9. I guess, steps 9 and 10 of the hosting workflow table + should be rethought. +10. In the section =Making an Update request=, the update + request could be made explicit by saying it is the update + of the registration +11. Can the registration update request happen without + reference to the prior registration? Is the application + id reference to it? +12. The first step in the table describing the update + workflow is not clear to me. +13. Similarly, the first step in the de-registration request + workflow looks ambiguous. Why are hosting request + parameters required. Probably, we want to state that a + registration request has happened earlier. +14. Is it a cut paste error in the column =Action taken by + Actor= of the table =Suspension Workflow= table where + Registration is put in brackets. + + + + + diff --git a/src/labs/uniform-ui.org b/src/labs/uniform-ui.org index 248f4fa..43e55e0 100644 --- a/src/labs/uniform-ui.org +++ b/src/labs/uniform-ui.org @@ -2,67 +2,80 @@ #+SETUPFILE: ../org-templates/level-1.org * Summary - The principal work of this project is Designing a browser based generic User - Interface for experiments in Virtual Labs and its =auxiliaries= '. Our aim - is to develop a browser based application that would act as an interface - between the user and the =processing tool= using predefined protocols. + The principal work of this project is Designing a browser + based generic User Interface for experiments in Virtual + Labs and its =auxiliaries= '. Our aim is to develop a + browser based application that would act as an interface + between the user and the =processing tool= using + predefined protocols. - A =processing tool= implies a relevant hardware/software which would receive - the data from the interface, process it and return suitable data to the - platform for predefined action(primarily display) + A =processing tool= implies a relevant hardware/software + which would receive the data from the interface, process + it and return suitable data to the platform for predefined + action(primarily display) - =auxiliaries= are Remote Triggered labs, Simulation based labs etc. + =auxiliaries= are Remote Triggered labs, Simulation based + labs etc. * Background of the project - Due to lack of a unified 'experiment development platform' in the virtual - labs community, robust development and maintenance of the labs becomes - tedious. This demands resources for maintenance and integration of these - labs. + Due to lack of a unified 'experiment development platform' + in the virtual labs community, robust development and + maintenance of the labs becomes tedious. This demands + resources for maintenance and integration of these labs. * Details - The application is to be modular and robust, to cater the needs of the - specific experiments. The developer is expected to create various - prespecified functional pallets which would be embedded in the application - framework as per the requirement. + The application is to be modular and robust, to cater the + needs of the specific experiments. The developer is + expected to create various prespecified functional pallets + which would be embedded in the application framework as + per the requirement. - A two tier programming is proposed in the broader level wherein our current - requirement is to develop a modular robust platform and suitable palets. The - level 2 programmers / experts would then easily use those pallets and the - platform as a visual programing editor to custom make the interface for a - particular experiment. + A two tier programming is proposed in the broader level + wherein our current requirement is to develop a modular + robust platform and suitable palets. The level 2 + programmers / experts would then easily use those pallets + and the platform as a visual programing editor to custom + make the interface for a particular experiment. - It is a browser based Visual Programming Editor, where the user can create a - flowgraph on canvas by dragging and dropping blocks from library option to - main canvas area and in runtime, while simultaneously taking care of its - logical counterpart. Logical blocks would be created by using a programming - interface wherein the developer has the choice to write the functionality - using any programming language. Each block shall have capability of - communicating to adjacent blocks. Blocks are of three types: Source, Sink - and Functional. + It is a browser based Visual Programming Editor, where the + user can create a flowgraph on canvas by dragging and + dropping blocks from library option to main canvas area + and in runtime, while simultaneously taking care of its + logical counterpart. Logical blocks would be created by + using a programming interface wherein the developer has + the choice to write the functionality using any + programming language. Each block shall have capability of + communicating to adjacent blocks. Blocks are of three + types: Source, Sink and Functional. - Source: Source block will fetch the data from the GUI - - Sink: Sink block will send the data to the GUI - - Functional: Functional block will perform the operation on the input from - source blocks and forward the output value to the sink block + - Sink: Sink block will send the data to the GUI + - Functional: Functional block will perform the operation + on the input from source blocks and forward the output + value to the sink block - While developing this application, developer will have to keep in mind that - blocks will have to get used in application where it will have to communicate - with some hardware so there should be an option where user can give the - sampling rate. Security and ease of development are also important in this - regard. + While developing this application, developer will have to + keep in mind that blocks will have to get used in + application where it will have to communicate with some + hardware so there should be an option where user can give + the sampling rate. Security and ease of development are + also important in this regard. * Benefits of project - 1. It will help to create experiments virtually, which can be used - by students at remote centers. + 1. It will help to create experiments virtually, which can + be used by students at remote centers. 2. Student can use this application for simulations. - 3. It shall abstract the programming from end user. which means that it can - make programming possible for the person only with domain knowledge. - 4. The open source community has an advantage to collaborate and contribute - in the early stages of the development of the application. + 3. It shall abstract the programming from end user. which + means that it can make programming possible for the + person only with domain knowledge. + 4. The open source community has an advantage to + collaborate and contribute in the early stages of the + development of the application. * Required Deliverables - 1. To create a canvas which has options of drag and drop and make - connections. + 1. To create a canvas which has options of drag and drop + and make connections. 2. Be able to work on web as well as on local machine. - 3. Ability to execute flowgraph and show the user interface just beneath the - blocks, respectively. - 4. Interface to create a block using any programming language. + 3. Ability to execute flowgraph and show the user + interface just beneath the blocks, respectively. + 4. Interface to create a block using any programming + language. diff --git a/src/org-templates/level-0.org b/src/org-templates/level-0.org index 48b7660..24313e5 100644 --- a/src/org-templates/level-0.org +++ b/src/org-templates/level-0.org @@ -4,7 +4,7 @@ #+DESCRIPTION: #+KEYWORDS: #+LANGUAGE: en -#+OPTIONS: H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t html5-fancy:t +#+OPTIONS: H:3 num:3 toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t html5-fancy:t #+EXPORT_SELECT_TAGS: export #+EXPORT_EXCLUDE_TAGS: noexport #+STARTUP: hidestars @@ -16,6 +16,5 @@ #+HTML_HEAD: #+HTML_HEAD_EXTRA: -#+HTML_HEAD_EXTRA: