i want to create a web chat/forum application that is google wave alike.
when one person is typing a new post or embed an image in it other persons are seeing this live.
i have read about different techniques and i feel that long polling and iframe are the most talked about.
so, which one should i use for this application and why? i've read something about that the long polling is great for long update intervals. cause if it's a chat, then it has to request new data for every keystroke..and that is like polling every second when typing. so based on this, i should use iframe so that there is only one connection all the time?
what technology is meebo/google wave using?
Long polling sounds like a good choice for this kind of application, but you might want to consider having some kind of delay/buffer period between key stroke and server callbacks. It doesn't have to be very long (less than a second) to give a serious speed gain.
You might also want to consider using Adobe Flash as a bridge between the client side javascript and your own custom communication protocol. This offers better control and less overhead, but comes with the price of a client side plugin dependency.
Last, but not at least, you might want to consider building your application on top of Google Wave. Unless your are building a clone of Wave for the sake of building a clone, it might provide you with a lot of the infrastructure you need.
I'd hate to sound harsh, but I think you might need to dig a bit deeper into the subject, and return when you have a more tangible question.
The non iframe like technologies are collectively called Comet, and since you didn't mention any specific language you want to use could try to use CometD which has recently been released and should you support in what you want to do. Or you just dig directly into Google Wave programming since it already seems to have everything you are looking for. Personally I always found all the iFrame solutions a little iffy.
Related
I am building a massive real-time collaboration web application. It is a Web IDE that has support for HTML, CSS & JS programming and a stage area that would reflect the results a la JSFiddle, Plunker etc.
Now, the twist is that, it would support multi-user real-time collaboration, where people viewing the same instance of the web application would be able to write code together that would reflect across all the open instances. I have figured out the race conditions, session management et al
What I am having trouble with is
how to reflect the typing and/or deleting along with caret positioning
across these multiple instances giving the illusion that when one
person is typing, he is actually typing on all the instances.
The other thing is that RactiveJS says that it
updates only those parts of the page that are out of date. Tedious DOM
manipulation is a thing of the past.
Which is a very nice effect in their Demo. Imagine, you are on JSFiddle and you don't have to re-run every time. So, my question is, how do they do it? What is the concept behind it?
I don't want to use any library for this. I am pretty good in JS. I am having a hard time figuring out the algorithm.
Things I have considered:
Dirty Checking [but, its dirty right?]
Delta Differencing [but like ReactJS, it would have to update the entire application state every time]
Object.observe [the browser compatibility is not realistic yet]
So, if you have anything that can help me go in the right direction, I would be really thankful.
Realtime-collaboration tools, that allow concurrent editing/manipulation of objects/texts etc, usually use a variant of the Operational Transformation algorithm.
OT is not trivial to understand, much rather implement so I'd suggest you take a look at already-cooked libs for this such as:
ShareJS
Racer for Node
OT works, in some very basic way, similar to GIT
As an update to what you posted in the comments.
You say you are using Python. You wouldn't rebuild your whole codebase, I guess, but keep in mind that real-time collaboration tools usually benefit a lot from using an event-driven server-side language.
Since you are using Python, you could check out the Twisted Framework
I am building a completely ajax web app (this is the first web app I have ever created). I am not exactly sure if I am going about it the right way. Any suggestions or places where I can go to find suggestions?
Update:
I currently am using jQuery. I am working on fully learning that. I have designed a UI almost completely. I am struggling in some parts trying to balance a good UX, good design and fitting all the options I want to fit in it.
I have started with the design. I am currently struggling with whether to use absolute positioning or not and if not how do I use float etc. to do the same type of thing. I am trying to make it have a liquid layout (I hate fixed-layout pages) and am trying to figure out what I should use to make it look the same in most screen sizes.
Understand JavaScript. Know what a closure is, how JavaScript's event handling works, how JavaScript interacts with the DOM (beyond simply using jQuery), prototypal inheritance, and other things. It will help you when your code doesn't work and you need to fix it.
Maintain usability. All the AJAX magic you add is useless if users cannot figure out how to use it. Keep things simple, don't overload the user by giving him information he doesn't need to know (hide less important information, allowing the user to click a link to show it), and if possible, test your app with actual users to make sure that the interface is intuitive to them.
Code securely. Do not allow your server to get hacked. There are many different types of security flaws in web apps, including cross-site scripting (XSS), cross-site request forgery (CSRF), and SQL injection. You need to be well aware of these and other pitfalls and how to avoid them.
One starting point is to look at the Javascript Libraries and decide which one to use:
http://code.google.com/apis/libraries/
http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks
You probably don't want to do raw Javascript code without any library. Once you decide on a library to use, then you can look at its documentations online or the books about using them. jQuery does have pretty good documentation.
Define "right way."
There are many "right ways" to code an app.
Things to keep in mind are trying to design a nice interface. The interface can make or break an application and studies show that it can even make it seem faster if you do it right. jQuery is good for this.
Another thing to consider going in is what browsers do you want to support? Firefox is really doing well and Google Chrome's market share is growing so you will want so support those for sure. IE is a tough one as it doesn't have the best support for standards, but if you are selling a product you will really want this.
One of the best articles that I've ever come across about the structure of an ajax web application is this one. A little outdated because it refers to XML as the primary data-interchange format, now JSON. jQuery, a javascript framework, contains excellent functionality for both DOM manipulation and AJAX calls. Both are a must in any AJAX-driven web app.
It's not the type of game that really need a server to operate. I'm using javascript and html5 right now, and I cant think of a way to prevent the game from being rip off.
Using obsfucator is useless, the game would still work offline.
Implementing a validation scheme is not invincible either. Someone smart can just crack the script and remove the validation part.
Make it attractive for users to play on your site.
For example:
Provide online Highscores.
Introduce a multiplayer option
Create friends list
Provide a server based achievement system
Develop other games and provide them on the same page so users want to come back
Create "level packs" and similar add on content and release them on your page
Overall, there are other possibilities to get users to play on your site besides technical restrictions, which - as you already found out - are difficult to deploy in an open source, browser driven environment. But, on the web, this has always been a feature, not a bug.
You're right in that a clientside-only can't be prevented from running offline. How about moving part of the game logic to the server?
You could continue to use html5 and javascript, but move your javascript to the server side using node.js For example http://www.yuiblog.com/blog/2010/09/29/video-glass-node/
If you combine obfuscation and validation, you'll go a long way. Can someone crack and use it offline? Possibly. Is it really going to be worth the effort? I mean, even an installed game can be cracked. This is especially true if you make the validation extra obfuscated by hand by spreading it out over several methods.
I would avoid moving more logic to the server than you have to, because it would obviously slow the app way down, but you might be able to get away with moving tiny crucial pieces that only happen rarely like between levels (chapters?).
How important is it to gracefully degrade or inversely Progressively Enhance the UI experiance? I mean am I going to lose a LOT of business if I don't? Do you practice this concept? Are there any web 1.0 users still left out there?
Please could you also include if you practice this personally and how much time you've spent relative to the entire project. I realize every project is different, I want to get a sense of how much time as a general rule I should be allocating toward this goal.
EDIT
Firstly, i'm looking for guidance around how much time I should be devoting to making my applications run without javascript.
Secondly, the BS term "web 1.0" (...lol... I don't really like it either) works because we all understand that as the iteration before ajax and all its goodness.
Thirdly, the kind of applications I'm describing are the ones we are all building, not Facebook, not Twitter (unless you're from Facebook or Twitter) but service or utitlity programs like a web calendar, or an online todo list or [INSERT YOUR APP HERE].
Progressive enhancement is more a mindset than a particular task that you need to allocate time to. If you're doing it right (and if it's important to you), you should be enhancing the user experience with JavaScript, but not relying on it.
For example, a link will point to a new page, but with JavaScript you'll disable the link and load new content into the current page with Ajax. Start off without JavaScript and progressive enhancement will follow naturally.
Progressive enhancement is not only smart but it is faster and easier to develop.
And at each stage, you almost always have a working fall-back.
Here's what it looks like in a nutshell:
Boss/client approves mock ups.
We code to valid HTML output. At this point, the boss/client can start using the site. Baring any boss/client changes, the HTML is mostly done. The site is usable at this point.
We start tweaking the CSS to make it match the boss/client's graphic expectations. Changes to the HTML are minor, if any.
In parallel, JavaScript is added to do non-critical, but nice, things. (Sort tables, Fancy CSS helping, replace some links with AJAX calls, warn the user -- client-side -- of input problems.)
If any one of these things breaks, the site still works.
Also, little, or usually no, html changes are needed.
First of all, lets not start using bullshit terms like "web 1.0" and "web 2.0" etc, the fact is the web is forever progressing and new websites are starting to use JavaScript to enhance the user experience.
I don't know anyone that doesn't allow their site to gracefully degrade when JavaScript isn't available, this is for the same reason we use semantic markup so screen readers can correctly interpret our websites for users with visual impairment, and whilst the vast majority of your visitors / users won't fall into these categories it's still important to think about the minority.
Will you lose a LOT of business, well that depends on how successful you are now and how badly your site degrades, chances are you probably won't lose any business... but that should not be the measure yo use to decide whether to gracefully degrade a website.
So unless you can come up with a pretty good reason, you should probably use JavaScript for the purposes of progressive enhancement, don't depend too much on it.
:-)
This greatly depends on the nature of your aplication and its data. If it's something that you know will be mostly used via computers, than degrading to non-script version UI wouldn't make any obvious benefit (even loss of money because it will take considerable time to develop). You can always tell people to enable javascript in their browsers (similar to what's done here on Stackoverflow - try disabling script and reload the page). Your app/site should display at least something when there's no Javascript posibility.
But if your application has simple data to display and users should access it frequently wherever they are, than degrading to lesser browsers (without script engines like Opera Mini) is a must. Creating a separate UI will less functionality, but keeping everything in that users need to access is probably your best option. UIs like separate iPhone applications for example...
JavaScript is disabled by a small proportion of web users, but when you start to talk big volumes this can make a difference. For example for 1 million visitors, you can expect more than 10,000 not to be able to user your site.
You should decide how much lost business is worth the additional cost of having a non-JavaScript version of your site.
You can have an approach where the entire site may not work without JavaScript but that some of the core features are there.
My boss wants to draw the local network and then, if you click on one of the computers or roll the mouse over one, he wants to see stuff like RAM, CPU, OS, etc. This has to be done in a browser, more specifically, the intranet's wiki.
One of my coworkers suggested using flash (I am a complete noob but I assume ActionScript is what would be used?) and I think it could also be done in javascript but I dunno. Not sure what would be better.
He wants it to be extensible if possible, so adding another computer later or editing values shouldn't be too hard, though the topology shouldn't change very often. This may be up to me to code a separated way to edit it though, I dunno.
Any thoughts/recommendations?
Up until one of the recent versions of Visio (2003?) there was a very useful network discovery tool that would build the diagram. Then using the Save As HTML option there are a number of different ways to build the clickable diagram.
I'd imagine other network diagrammers can do the same.
This is the easiest way I've ever found to do what you want. The only downside I'm aware of is that the Visio discovery will send a significant number of packets; it can flood a network. However in my opinion if your network is that susceptable to load you want to know ASAP. Preferably with a job you can stop and start at will.
Don;t forget that any process you arrive at should be able to rebuild your diagram regularly, e.g. once a week or a month.
The technology you want might be called an HTML Image Map.
It might be cost-effective to purchase a monitoring system.
OpManager is pretty easy to use and provides the graphing capabilities.
Paessler is less expensive, still details, but doesn't have the graphing capabilities.