Reading Programming

I think that it is nice to have both the server and the clients in the same language but it is not an absolute necessity. We can explore the possibilities of writing the server in the language which is suitable for the job, and can write the clients in any language for any platform that we wish for.

The server side
Lets itemize the problems that the server is going to solve. Then, based on that we can decide which language will be the best. Here is my initial try to list the things that the server will do:-

Functionality 1

Communicate with the NAO server to get data (new posts, other statistics)

Publish it all the clients that have subscribed to its service.

We might have multiple types of subscriptions, some client might subscribe to all the types of messages, some client might subscibe to only broadcast/important messages (special messages/NAO updates from the NAO admin (Jaz)).

Functionality 2

Allow multiple users (clients) to communicate with each other (pager functionality) via this service.

Keep a history of such communication per user if the user desires so.

Enable/Allow voice communication between NAO messenger users

Allow the users to share applications/send files.

For now, it looks like we need a pretty simple model - an application that should be able to send and receive messages in a standard format (some protocol that we have decided upon), and store a history of such messages per user.

So, the current problem can be solved by any of the following languages C++, perl, python, C, Java and .NET.

The Client side
The client side needs to have a proper GUI to display the messages, and should be able to probe the server periodically to receive messages and/or the server should be able to send messages to these clients. So, the clients should be written in a language which has good GUI support (Java, and .NET come to my mind immediately).

Which language shall we use for the server?
Okay, that still does not answer the question as to which language shall be used. For the client side, I think we have more or less unanimously chosen it to be Java. However, since we are going to make it an open-source, and will release the specifications, anyone is allowed to build the client in whatever language they desire. It is the server that we have to decide now!

If null is able to upgrade the server it would be great. If we use the current P75, then we should go with C++ or C. I feel so helpless. I have permanent DSL connection at my home, and my home computer is on all the time, my wife uses it to communicate with her relatives and friends in India and other places. Apart from that we dont use the machine ever. It is a Pentium 4, 1.7GHz, 256MB DDR SDRAM, 40GB hard disk. The only sad part is that it runs Windows XP Home edition, and since we are under the current warranties of Dell, if we change the OS, the warranties on the system will become void. So, it looks like I can not do anything in spite of having such a machine at home :(.

Love is blind, but marriage is a real eye opener.

This post was deleted by request of the author.

This post was deleted by request of the author.

The only problem I see would be that you're the only one able to run/debug the server. If you don't mind this (and probably even got a static IP), I don't see why it wouldn't work.

...Provided you're willing to let us use your computer ofcourse. :-) But I assume you wouldn't have offered it if you didn't.

What do you think?

When life hands you a lemon, that's 40% of your RDA of vitamin C taken care of.

This post was deleted by request of the author.

NAO Integration
I totally agree on the NAO Integration section. We definitely do not want to give many functionalities to the messenger and would definitely not like it to replace the NAO website. Its purpose is to just integrate/link the NAO user to the website "all" the time. So, by instantly sending messages to the user about a new post being added to the website in a particular forum, the user is prompted in a way to "go" to the website to read the post.

The pager in the NAO messenger would merely replace/complement the functionality currently existing on the NAO website, and if NAO messenger is successful, the current NAO pager can just make calls to the new pager, thus, shifting the load to the server where the NAO messenger is hosted.

Server (hardware)
Can't really comment on this because my hardware knowledge is nil.

Server and Client (software)
If everyone desires that the client and the server should be written in the same language then I too support Java. The only worry I have is performance of Java clients on a windows machine. I mean there won't be any problems of porting the clients on a .Net language (C#, ASP .NET) and the performance would increase 10-fold. We can investigate this later on. For now, I am with Frank that we should use Java.

Even though all my expertise is in C++, I wouldn't suggest using that, because after using C++ for almost 8 years now, I feel that it is not suited for complex or business applications. It is very good for learning the programming concepts, but when it comes to handling real-time problems, the focus of the programmer shifts from solving the problem to using the C++ concepts. This takes more time, and still leaves many holes as no one can write the "perfect" program. Just my 2 cents on this one.

Love is blind, but marriage is a real eye opener.

This post was deleted by request of the author.

Sorry for not replying earlier, there was a lot to be taken care of. Null sent me little SMS reports about this while I was in France, although I'm afraid half of them got gulped by the French GSM network.

"Statement":

- You want to use a seperate server for your project, but still the data has to be pushed or pulled from NAO to this very server. This amounts to an awful lot of traffic, which is a PITA when you've got to move servers. I still remember how much of a PITA it was when I had to find a new hosting company some years ago and came up with the 150$/month hosting plan everywhere since the Coder's Knowledge Base with all it's traffic was still being hosted on NAO.

- As I said, I don't want to provide an API. So if there's communication between the pager and NAO, it would only go one way.

- Maybe I could provide data feeds for some things, but since I'm about to move to another city and start college I'm a little busy, and I have so many ideas for new, funky stuff for Netalive.org. I'd much rather like to implement these things in the spare time I have left, as they would probably be more useful to most users than the pager (which probably only the coding crew would use for some time) - It's really cool stuff you know :) Short, I don't know if I can give you the level of dedication that you might need.

That's it for now... in my opinion you should consider Frank's opinion that the project should not be 100% dependent on NAO. If you really pull this off, you would have invested too much work in vain if NAO stops playing with the pager some time in the future.

'Yeah, That's what Jesus would do. Jesus would bomb Afghanistan. Yeah.' - snowlion

- As I said, I don't want to provide an API. So if there's communication between the pager and NAO, it would only go one way.

'kay. Not a big surprise anyway. :-)

in my opinion you should consider Frank's opinion that the project should not be 100% dependent on NAO.

I support that. As I said before (? If I didn't forget it anyway :-) ), the whole thing should basically work by itself and just provide NAO access as an add-on.

I don't know what will happen when the pager finally works. I guess it depends on how many people we can talk into using it. :-) For me (I can't speack for the others) the primary motivation is that I've thought about building a pager for years, and finally there might be a chance to do it. I will definitely use it as long as I'm not the only one. :-)

When life hands you a lemon, that's 40% of your RDA of vitamin C taken care of.

This post was deleted by request of the author.