User:Inderpreet/OGV Proposal

From BRL-CAD
Revision as of 04:32, 18 March 2014 by Inderpreet (talk | contribs)

Online Geometry Viewer Project Proposal

Personal Information

Name: Inderpreet Singh

Email Address: indrplus@gmail.com , singhs.ishwer@gmail.com

IRC Username: Ishwerdas

Background Information

I study in 4th year B.Tech (Computer Science and Engineering) at Guru Nanak Dev Engineering College, Ludhiana (India). I Introduced myself in this community about a year ago and have tried to help with whatever I could. I can speak in C++, PHP, Python, Javascript.

Project Information

Brief Summary

Online Geometry Viewer started as a GSoC 2013 project by Harmanpreet Singh. It's an online 3D geometry viewer that works on WebGL using three.js. For the server side purposes currently it uses vanilla PHP and jQuery, Bootstrap on the front-end. To give it a robust foundation, the community discussed about changing it's backend to something more powerful. I was part of that discussion and I gave my views. We all agreed on node.js to be a replacement for the current PHP based backend. We also agreed to use a Full Stack node.js framework such as derby or meteor. After looking at various frameworks I have decided to go for meteor. Reason for this choice is meteor has a comparatively larger community which means more support, bugs removed quickly and more code to learn from. Then there's a list of things that need to be improved in current OGV and a list of features that need to be added.

Things that I will Improve on: -

  • The way data is handled about models. (Currently GET method is used)
  • The way errors are given. (Many of the errors are not given at all)
  • The way Authentication is done (Will be handled by meteor now)
  • Use of obj files that we already have
  • Installation and Configuration
  • User Experience and User Interface

The features that I will add: -

  • User Roles (Will be handled alongside Auth Module)
  • Dashboard
    • Various dashboards based upon user roles (Admin, non-admin)
    • File manager, to see previously uploaded models.
  • Social Geometry Viewing
    • Like Models
    • Share Models
    • Comment on Models
    • Fork Models
    • Embed them in website
  • Image alternatives for 3D Models (Requested by Mediawiki)

Detailed Project Description

As it's clear from the previous section the project is divided into three parts

  • Porting OGV to nodejs (meteor)
  • Improving the old and removing the bugs
  • Adding New features

Porting OGV to node.js

Online Geometry Viewer is currently written in plain PHP, and in discussions we all have agreed that we need to change that into something robust. Various suggestions were made and the Idea about using node.js survived. Then there was a choice to be made among various kinds of frameworks, and then various frameworks in each kind. We decided to go with Full Stack frameworks like derby or meteor. I decided to choose meteor over others because of it having a larger community thus more support. It's also extensible with plugins and packages.

Improvements in OGV

After we have a sound foundation with node.js, now we can concentrate on improving the existing OGV features.

Models Data Handling

Currently in upload_file.php, a list of names of obj files is sent to model_display.php using GET method. We can send a very limited amount of data through Get method. Larger models fail to get loaded because of this limit. It's just an array of file names so I will use HTML5 local storage to store this array locally on the client and fetch it again from there.

This will remove the bug and also add all the speed and benefits that come by storing data locally. Few older browsers do not support local storage so for them we can use a polyfill such as amplify amplify.js. Fortunately meteor has a package called amplify, that does exactly the same thing. Not just for this one bug, we can use local storage at various places to make our app feel more native.

Errors

No matter how much we hate errors, they are very important to the user. They tell something is wrong and they contain information about solving itself. Can they be any nicer? Currently at some places errors are not given to user at all and at other places errors are not that explanatory. For example there is no error given if the user account folder is deleted, neither a remedy is taken to create the user folder again. Just the models are not displayed in model_display.php without any error or any indication of something that has gone very wrong behind the walls. Then there's a case with configuration errors, if say mged path is wrong then there's a small error in the sidebar of the model_display.php. Which is not clear and also gives no cue to user about how to solve that error. For other errors like mysql credentials, I believe bootstrap's alert class needs to be used, so that it looks like an error. It's half of a UX problem and half of the functionality problem. For configuration errors, I have submitted a patch to the official github repository.

Auth Module

As also