dondi / quo Goto Github PK

This turns out to be a prerequisite issue to some of the others that are already here: the possible status destinations and their associated code/data need to be restructured so that they are more modular. They should be separated better so that they can be developed independently of each other. This restructuring should also help with user profile management, particular with regard to the assorted social network accounts that a Quo user might have.

Some broad strokes: the code for each destination should be placed in separate files. Further, the status-posting service should separate shared status-posting logic (i.e., running statuses through the pipeline functions) from service-specific activities (i.e., Twitter API, FB API, etc.).

In addition, the user profile information that relates to the different social network accounts should be well-integrated with this status design.

This depends on #3 for full completion, but can be started before that issue is done. We already have a user profile page of sorts; without the underlying services, we can at least make those pages show up at the right time/place, then implement any needed interactivity up to the point where we need to call the service.

With Twitter done, we should now turn our attention to Facebook. This may require some refactoring to the /statuses POST implementation. User profile data may need to be updated as well.

Returns 204 on a user creation via /users/{username} with no password; does not create the user profile, but logs error message to the console. Failed user creation should return 400, which is implemented correctly for a POST to /users.

The Quo codebase does not currently have a unit test suite. It should have one.

Tests to cover include:

• Database tests
• Service tests
• Authentication tests
• Status function tests (e.g., Does removeHash really removeHash? Does truncateTo140 really do that, with ellipses at the end to indicate truncation?)

For database tests and possibly the other types as well, a database test fixture would need to be developed.

Status function tests are probably the most straightforward ones to develop at this stage.

This is a key feature of what Quo should be able to do, but of course is more than just a simple string manipulation. We should sit down and talk this through.

After the refactor, both the function-service.js and status-service.js need access to the available library of status-changing functions. This code is currently copied and needs to be unified.

Our pipeline function collection should be moved to the database now, with accompanying services (documented in the wiki and currently implemented in mock form). This opens the door for (later) creation of new functions that can be used in the pipeline.

We will also have to accommodate some “native” functions. One key such function is the contact/friend/link converter: that requires a lot of additional information to implement well, and of course would not be definable by a user on the fly.

It’s time to fully implement user profile creation and modification. First, we do services. This means implementing (per the wiki documentation) /users POST (creation with no preset ID) and /users/{username} PUT (modification, or creation with a preset ID). We should follow REST for both, of course. Passwords may require special handling.

Our status page has reached the proof-of-concept level, and now we need to go beyond it. Missing elements include:

• The status pipeline display
• A status preview section (one for each endpoint in the pipeline)
• Links for triggering sign-in (ideally, we can query sign-in status for each service, so the user can tell if sign-in is necessary)

This will probably require a full talk-through session where all of us sketch things out and walk through all of the relevant behaviors and use cases.

The login/logout cycle in Quo has not been fully implemented. Some beats:

• It is possible to go directly to /main (or other pages that presumably require a login) without logging in.
• There is no login session such that a given page cannot tell which user is logged in.
• Web services can be invoked freely without an authentication challenge.

These need to be implemented.

This is an internal code structure issue: we should separate Node routes that respond with pure data (i.e., services) from routes that respond with web pages (i.e., views). Conceptually they are different things, so our code should reflect this. /index and /main are views, for example, while /functions and /statuses are services.

Each Quo user is supposed to have a family of associated destination accounts (e.g., Twitter, Facebook, etc.). The Quo web app must ensure that when a Quo user logs in, the correct associated destination account is used, as opposed to, say, whatever account was last stored in a cookie or other external persistent state.