Server Framework

[sre42]

I was browsing through about GWT, and I have found a great Stack overflow link that shows the difference between Spring and GWT. http://stackoverflow.com/a/13719522/3255842

After searching for Server Frameworks, I was able to compile this list: Spring - JAVA Symfony2 - PHP Laravel - PHP Django - Python Ruby on Rails Ruby Node.js - JavaScript Angular JS - Java Script

[peterGraf]

Ok, that sounds as if we should start with Spring.

[sre42]

Allright, I will continue building on Spring for now. But we can switch If It doesn't work out for our specifications.

[peterGraf]

Hi Omar, how about goint throug the list of requirements given in https://github.com/peterGraf/ARVOS/wiki/ARVOS-Directory-Service-_-Technology and writing 3 lines for each requirement about how that requirement could be fullfilled using the Spring framework?

[sre42]

Im on it.

[sre42]

Directory Service Requirements

• The directory service must be very fast for channel queries.
  • Performance evals showing Spring as one of the Fastest frameworks: http://blog.websitesframeworks.com/2013/03/web-frameworks-benchmarks-192/
• Ease of deployment of the service is not a consideration.
  • Not a consideration, but can be easily packaged (using Gradle) into Jar or War to be deployed.
• The channel data must be stored in a way that allows efficient queries by location, channel name and author name.
  • Data shall be stored as H2 or Sqlite, It may not be as efficient as a separate database server, but the ease of setup are our main concerns right now. Spring can also be easily ported later on into Mysql,MongoDB, etc.
• Channel name and author name queries should allow matching of channels, e.g. a query for author name 'doe' should show all channels by 'John Doe' and by 'Jane Doe'.
  • Custom queries can be built using standard Java such as here: http://github.com/Omarasifshaikh/Arvos-server/blob/master/src/main/java/com/arvos/server/model/InMemoryAugmentRepository.java
• Channel queries should use HTTP as request protocol. Query responses should be given back in JSON.
  • Already implementing HTTP and Json: http://github.com/Omarasifshaikh/Arvos-server/
• The data storage technology used should have zero administration overhead.
  • H2 or SQLite. H2 has better performance and supports encryption.
• HTTPS must be used as protocol for the administration interface.
  • Administration interface has to be setup using Spring MVC or another front-end framework such as GWT(Performance implications).
• The administration interface should work on all web browsers used by the authors.
  • Will test it with the latest iterations of Chrome, Firefox and IE.
• The administration interface must have a super user mode, which allows the super users to override data managed by the authors.
  • A separate permissions group will have access to the special user management interface.
• The administration interface must allow new authors to register with ARVOS.
  • Users will be stored as user entities. they will also have their own profile.
• The registration of new authors must verify the author's email by sending a registration response email before the author's account is activated.
  • Users will be asked to verify their emails before being able to post content.
• The author registration used should have zero administration overhead.
  • Automated by the server.
• The author registration must not store the author's passwords in the service. Properly salted hashes to the passwords have to be used.
  • This issue needs more research. A future milestone will include Single sign on using the popular SSO services.
• The author registration should allow the authors to reset their passwords, this process must include email verification.
  • Basic user management. will try to find a library that manages users.
• It should be possible for authors to keep channels in 'develop mode' so that they are only visible for a selectable group of users.
  • Channel Entities will include this option.
• The administration interface should provide a map interface to the authors for placing channels at specific locations.
  • will use google maps or Open Street Maps to display Augments in a 2D map. Possible 3D map integration in the future.
• More than one location must be possible per channel.
  • Channels will have a one to many relationship with Augment entities.

[peterGraf]

Hello Omar, looks good, thanks!

Greetings

Peter

PS: We will be in the mountains Fri to Sun, without internet!