Open originalhat opened 11 years ago
Feature | iPhone /iPhone 3G | iPhone 3GS and newer | ![]() Android 1.0 – 4.2 |
Windows Phone | ![]() 4.6–4.7 |
![]() 5.x–6.0+ |
![]() Bada |
Symbian | webOS | ![]() 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 |
There are a lot of frameworks for IRC out there... I saw a lot of Java and Python....
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.
Interfacing with existing servers? TODO. How the fuck do I do that.
What about node.js?
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.
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.
:angry:
YOU SACK OF :poop: @EGartin LOLOLOLOLOLOL
Something I need to research: possible implementation details for managing multiple users w/ multiple chat sessions using GSERVER.
I invision the following layers of functionality...
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.
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.
This will be 100% graphical and will simply tap into the existing "Middleware" API.
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).
I like what you're saying, the Restaurant Analogy was a nice little addition... :football: SMART
Research and pick technologies that are the best tool for the job.