dertseha / eve-upro Goto Github PK

I expect the client to be run on a multitouch device as well, so, default behavior should be disabled; But also actual functionality provided - at least for the map.

Reference: http://www.html5rocks.com/en/mobile/touch/

The autopilot service component shall receive a route from the client and store it for the character. It can hold and notify only one current route. Combining the current location, this service notifies at which index of the route the character currently is.

Group controls (adding, removing, joining, ...) should be part of the basic data model system (based on command / notifications).

I'm missing some log entries, such as

• user logged in (who?)
• session started (eventSource started)
• session lost (connection lost)

Also, as it is currently behaving, I furthermore think that the HTTP logs can be TRACE instead of DEBUG.

Some logging framework shall be added. Logging to console and/or file shall be supported. File logging shall support rotation.

log4js looks great, possibly use that one; Even includes a logger for connect.

Having an existing current route it shall be possible to set this one as the route for the autopilot.
A 'Clear autopilot' command is a nice to have.

When the autopilot service component skips transit systems for optimization, this is not equally handled in the client when feeding the autopilot.

I'm yet not sure whether the route should be cleared and set new (risking disengaging the autopilot) or this skipping should be deactivated.
Then again - when straying from the path this was already done by the pilot - thus, no autopilot involved...

With the recent addition of the current location highlight there are now three different cases of highlights present.
Abstract the common code, unify its usage and clean up the mess.

While working on #47 I found that cloud foundry does not forward the IGB headers to the application. This is very bad considering that this is an important function for the application.

Internet searches and also some (clarification) request will have to be made.

As a first function to distribute data based on user requests, have the active galaxy ID be sent via the server. It also should be stored so that the next login will have the same galaxy displayed.

Given an active session 'A'
And an active session 'B'
And galaxy 1 is active
When session 'A' requests to switch to galaxy 2
Then session 'A' displays galaxy 2
And session 'B' displays galaxy 2

Given user 'U1' previously had galaxy 2 active
When user 'U1' logs in with session 'A'
Then session 'A' displays galaxy 2

Based on the core data model layer (basic identification and history tracking), create a command and notification layer that allows execution of commands and the distribution of bound notifications.

Commands modify the data model (write history entries), notifications are based on the history entries.

Consider history entries not to be only notifications, possibly also 'meta' notifications (for the lack of a better word at this stage): cases of added or removed group interest. Becoming a listener of an existing thing implies receiving model data.

Add user tables as per design.

The login page shouldn't look like some form of the 90s - try at least some better font and colors.

Now that all basic functions are available, create a first, simple integration test that provides read and write access to a database based data model.
The test, running in PHPUnit, shall be self contained (with exception of the dependent database) and create/delete all necessary tables at each run.

Only the group control and its notifications need to be verified. As a side effect, try to identify any reusable code blocks which can make it to dedicated helper implementations when accessing the data model.

Example:
Given an existing group with ID G1
And a registered user with ID U1
And user U1 is in control of group G1
And user U1 is up to date
And a registered user with ID U2
And user U2 is up to date
When user U1 adds user U2 to group G1
Then user U2 will receive all information about the group

Although the basic idea for user related tables exist, they are missing several functions:

• authentication mechanisms
  Although a simple password storage (hashed!) might be necessary at first, think about an authentication provider framework; Have a look at API verification and CREST as well. Consider a 'demo' provider as well. Although not focus, try to look at existing authentication mechanisms (OpenID)
• Client connections
  When authenticated, a client connection must be tracked and timed out after a while
• Sessions
  Client connections must be combined to sessions. Should more than one session be possible at a time? Is there any difference between sessions? The original draft contains a session specification, but since information is bound to a user, every session would know the same. Think about sessions specific resources as well (i.e.: audio output, ...)
• User control
  The system is planned to be invite-only. This needs a user managing user provided from the system. Also, must users be created from the manager, or are applications possible as well?

With authentication methods like OpenID, CREST and 'dummy' (for testing), an authentication framework shall be created that can handle several methods and can be used for at least the main interfaces and the admin interface.

It must be able to handle the query system of web requests and be transparent for the authentication methods used.

If the IGB is not set up to trust the site, it should be notified to the user. Best way is to include this message if no other message is displayed.

Create a mediator that handles the IGB functions - for now providing the ones for the autopilot.

It is a mediator since it is part of the user interface and has no relevance to the model.

The route of the autopilot should be yellow as in the client, while the active route to work on should be this greenish color.
This clarifies a bit what is what.

Apparently, when using a different system set up (such as on my Mac), PHPUnit can not be found.
Testing a bit around, I figured the include for PHPUnit.php can be removed by specifying an include path.

With the communications uplink available, create a data handler for the location service and the corresponding proxy.

Both data ports (for events and requests) are still open without needing a login - close them.

The authentication methods are using md5() currently to create the hash form the secret data; Try to use something more strong, such as PBKDF2: http://www.itnewb.com/tutorial/Encrypting-Passwords-with-PHP-for-Storage-Using-the-RSA-PBKDF2-Standard

This will require some configuration value later on - at least for the salt.

As per milestone

• create low-level, abstract DB access interface
• provide first MySql implementation

With the planned function to execute client functions via the IGB and the possibility of multiple connected sessions, the server must elect one of these sessions to be allowed to execute the functions.
This is to avoid any race conditions and/or any unnecessary executions.

The character-service component is the best candidate for this function as it also provides the basic settings data, which are some of the first to be received by the client.

With the group system available, create read/check methods for querying a users permission for control or access.
When created

• checks can be run for commands and their requested control/access permissions
• Notifications and a reset dump can be filtered per context.

Write the interfaces and (DB-specific) implementation for the core data model system (identification and history tracking)

As described per milestone, the existing JavaScript sources shall be imported.
This work package includes the corresponding unit tests.

Apparently I haven't read the corresponding documentation that much. The existing doc tags should be reviewed and fixed:

• it's "description \n @ var type" -- not "@ var type description"
• Clarify the proper specification of basic types (bool/boolean, int/number, ...)
• Do basic types need a backslash prefix?
• Perhaps more -- read documentation ;)

As per milestone description:

• Create a PHP based (web) app framework, with apps runnable through Web request and unit tests. (Consider console application as well for creating test pages)
• Create the main application (main HTML page as currently under test/manual) through this framework.

The main page is currently a placeholder. Reincarnate the main application page which fires up the client code.

With the data model definition classes properly prepared, create the missing ModelReader interface and corresponding handler code. When a client first connects or missed too much of the history, it needs to receive the whole model again.
To be able to do so, all the data from the model must be extracted.

Column property 'unique' is required for at least the data model name and user names - and all id columns.
An 'index' would also be good for all id columns.

Create a table definition of the core data model that enables the requested functionality

Write an create/update framework for the data model tables.
The code shall contain the definition of all the necessary tables and be able to create a new and update an old installation.

Add a rate limiter buffer for HTTP requests. https://github.com/jhurliman/node-rate-limiter looks very good for this purpose.

The primary intention is to avoid spam in the system, but it should be intelligent enough to allow (possibly degraded performance) for 'legitimate' users.

How about instead of one global rate limiter add one based on user.
For example:

• At most 100 requests per second from clients without session; excessive ones are rejected (temp. unavailable)
• At most 100 requests per second per character; excessive ones are buffered; This requires spammers to have more than one character to spam with

Parent buckets:

• At most 1000 requests per second per corporation; This requires several corporations in effect
• At most 10000 requests per second at all; To have some upper limit

The limits should be put to allow normal operation, or it skews response times for power users.

It is currently possible to login with the IGB while running a different character than specified. While I'm currently not yet sure whether this should be allowed at all (well, can't prohibit it anyway), it should at least not cause issues with the current location.

Given an IGB of character A logged in as character B
When the status request is received
Then the IGB headers should be ignored

The data chain for the current location is coming along nicely, add an overlay which highlights the current location.

The first integration test of #14 showed that creating and removing the database tables takes time. It would be great to have some sort of fixture setup once for a set of tests instead of each test doing it on its own.

Try also to find a way for having a dual use - i.e., running a single test will also have the setup/teardown if necessary.

Code has been prepared, branch set up -- commit it, merge back and hope the best.

The admin controls should enable someone to

• create/update a database setup (tables)
• create a data model
• administer main users (enable/disable)

The admin should be able to perform these steps either

• via web interface - the key to the database is its password.
• via command line (with implicit access)

With the autopilot route known to the client, have it be displayed in the map as well.

Try to see some common pattern with the active route display for refactor/reusage (Perhaps a later ticket).

Create a small framework for storing PHP sessions (_SESSION).
Try also to incorporate the _SERVER and _GET/_POST/_REQUEST stores.

At best try to have the R/W interface compatible to the OpenID session storage interface, so no adapter is needed.

Enabling the line

$this->dropTable(MySqlTransactionControlTest::$TEST_TABLE);

before parent::tearDown(); would block the transaction test(s) even if they successfully ended it and released the table locks.

Try to find out why.

The login stage in the client is currently a stub. Change it to establish the data link with the server (eventSource, requestSink).
This one is done when events can be received and the current status request is sent periodically.

Finally try to get the interaction with the map right (rotation!). Also try to be more adherent to the existing map with regards to display.

• Star icon
• Star color (security)
• map rotation
• mouse button/movement combinations

The stars look weird with a cross. Create a ball with transparent border like the real map has.

This was previously not done because of transparency issues. But by coming across
http://games.greggman.com/game/webgl-and-alpha/
applying the mentioned fixes might not only help with the stars, possibly also with the performance hit I'm experiencing.

Have a 'good' PHP OpenID library imported. An integration test would be good.

Sort out which of the existing libraries seems to be the most maintained one (use one PHP 5.3+ compatible).

It shall work with OpenID 1.1 and 2.0

• Import log4php, at best as submodule
• create a wrapper for local use
• put in some checkpoint traces

When connecting via HTTP, key information is transferred in plain text. If possible, have a detection running whether HTTPS was used and warn if not.
A redirection is not required, not every installation might have HTTPS.