search

originalhat / mothership

Bring the sexy back with an all new IRC interface that's seamlessly integrated across all devices.
0 stars 0 forks source link

Specify Technologies #3

Open originalhat opened 11 years ago

originalhat commented 11 years ago

Research and pick technologies that are the best tool for the job.

  • [ ] specify our technologies
originalhat commented 11 years ago

Some Links and Shit

originalhat commented 11 years ago

PhoneGap

Feature iPhone /iPhone 3G iPhone 3GS and newer Android robot.svg
Android 1.0 – 4.2		 Windows Phone Blackberry Logo.svg
4.6–4.7		 Blackberry Logo.svg
5.x–6.0+		 Bada operating system.png
Bada		 Symbian webOS Tizen logo dark.png
Tizen
Accelerometer Yes Yes Yes Yes N/A Yes Yes Yes Yes Yes
Camera Yes Yes Yes Yes N/A Yes Yes Yes Yes Partial
Compass N/A Yes Yes Yes N/A N/A Yes N/A Yes Yes
Contacts Yes Yes Yes Yes N/A Yes Yes Yes N/A Yes
File Yes Yes Yes Yes N/A Yes N/A N/A N/A Yes
Geolocation Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Media Yes Yes Yes Yes N/A N/A N/A N/A N/A Partial
Network Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Notification (alert) Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Notification (sound) Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Notification (vibration) Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Storage Yes Yes Yes Yes N/A Yes N/A Yes Yes Yes
ElijahGartin commented 11 years ago

There are a lot of frameworks for IRC out there... I saw a lot of Java and Python....

originalhat commented 11 years ago

U N R E A L IRC

Down the line we might want to utilize our own IRC daemon, but for the time being if we want to host our own shit...

UnrealIRCd is an open source IRC daemon, originally based on DreamForge, and is available for Unix-like operating systems and Windows. Since the beginning of development on UnrealIRCd circa May 1999, many new features have been added and modified, including advanced security features and bug fixes, and it has become a popular server.

originalhat commented 11 years ago

Interfacing with existing servers? TODO. How the fuck do I do that.

ElijahGartin commented 11 years ago

What about node.js?

originalhat commented 11 years ago

What about node.js?

TOTALLY DOWN FOR SOME R&D.

The only reason I'm sticking with rubyish shit atm is to avoid adding additional overhead. I know that w/ ruby / rails shit we can get up and running quick...but that doesn't always mean it's the best tool / solution for the J O B.

ElijahGartin commented 11 years ago

The only reason I'm sticking with rubyish shit atm is to avoid adding additional overhead. I know that w/ ruby / rails shit we can get up and running quick...but that doesn't always mean it's the best tool / solution for the J O B.

I'd rather get something up that works than you have to spend a lot of time doing R&D. I'll brush up on some ruby so I can be of more use then.

originalhat commented 11 years ago

B

A

W

L

I
N
ElijahGartin commented 11 years ago

:angry:

P

I

S

S

E
D
originalhat commented 11 years ago

YOU SACK OF :poop: @EGartin LOLOLOLOLOLOL

originalhat commented 11 years ago

Something I need to research: possible implementation details for managing multiple users w/ multiple chat sessions using GSERVER.

originalhat commented 11 years ago

I invision the following layers of functionality...

"Backend"

This would be handled via GServer and would managed all client / server connections.

Think of this as the M of MVC, but further abstracted to a more minimal level.

The goal is to have this backend usable, and independent from the middleware, in that we could effectively chat from the CLI, issuing commands (TODO: need to be determined) as we see fit.

"Middleware"

This abstraction would layer upon the backend, providing "advanced chat features", such as managing multiple users with multiple chat sessions on multiple devices. This is the biggest challenge, as we need to be able to efficiently interface with our backend for many connections with many chat-sessions.

This will be primarily Ruby / Rails based and will utilize the MC of MVC. This is where our API (core functionality) will be established. It would be desirable to have this API abstracted here such that we could make various functionality occur based on URL-behavior, etc.

"Frontend"

This will be 100% graphical and will simply tap into the existing "Middleware" API.

Restaurant Analogy

The backend will be the cooks of a restaurant, taking raw materials and ingredients, turning them into tasty food. There is no interaction between the customer and the cooks, this is handled by the middleware.

The middleware will be the servers, bringing together various dishes to be served and presented. They may have a small roll in preparing the presentation of food, but mostly their job is to collect orders from the customers, process those orders (to the cooks), resolve problems with the customer, and finally, to present the finished meal(s) to the customers.

The frontend will be the atmosphere established by the restaurant. The booths, the music, the tables. This provides the platform for eating food, but doesn't actually create, present, or server the food (passive, no action).

ElijahGartin commented 11 years ago

I like what you're saying, the Restaurant Analogy was a nice little addition... :football: SMART