Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

user:regForMessagesAtLocation #3

Open
grzesir opened this issue Feb 16, 2012 · 1 comment
Open

user:regForMessagesAtLocation #3

grzesir opened this issue Feb 16, 2012 · 1 comment

Comments

@grzesir
Copy link
Owner

grzesir commented Feb 16, 2012

The client will send the current user's latitude/ longitude, and desired distance and the server will store these values. Then, when messages come in the server should send these messages to users who are close to this location. Also, the distance value can be a square approximation to save on computing time.

@qartal
Copy link
Collaborator

qartal commented Feb 17, 2012

As we talked on the phone this is a kind of overriding openfire natural reaction to the message flooding to the people in a room. it will affect our server so much! we need to examine it carefully.
For example,
1- we should decide if the messages is sent by message protocol or it can be send by IQ! what specialties packet of type messages provide us that we might loose if we replace it with IQ messages.
2- we might not need to create a openfire room while creating a room in the system anymore
3- disable message flooding of openfire to the users presented in the rooms
...
these r some points that came to mind instantly, we certainly will have other changes in the system like push notification.
if we also need to change the type of the messages to three types : 1- posts 2- replies 3- comments , this also should be considered as well
taking all those issues in mind, I think the server would need a kind of major revision and design , which we should plan and design and divid it in small steps.

What I am proposing for doing that, is updating our documents of current system and also trying to document our next requirements. that help to 1- give us better understanding of what we want by illustrating all the changes necessary in one documented schema. 2- helps to reveal some unknown issues we might neglect without documentation 3- we can get other team members feedback 4- we can examine which parts are gonna be changed. 5- we can plan our project changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants