I checked out the site at http://www.w3.org/TR/webdatabase/ and I saw a huge banner there that said
"Beware. This specification is no longer in active maintenance and the Web Applications Working Group does not intend to maintain it further."
What's that supposed to mean? I was thinking of implementing something using this feature. But I don't want to implement something in it if its not going to be standardized(eventually).
Do you suggest that I go ahead working on it? If not, is there an alternative that would be standardized? Or is it just another spec that has been scrapped?
It means exactly what it says: the W3C has dropped the standard and isn't planning to do any further work on it.
You're looking for IndexedDB, which is under active development.
From three paragraphs further on in the document:
This document was on the W3C Recommendation track but specification work has stopped. The specification reached an impasse: all interested implementors have used the same SQL backend (Sqlite), but we need multiple independent implementations to proceed along a standardisation path.
If not, is there an alternative that would be standardized?
Web Storage
Related
I'm trying to find a way to launch a desktop application from a browser for os x. This application will be for customers only and should only be used for the hardware we provide.
I'd like to start off by saying I think this is a stupid idea. I'm being forced to use this approach by our CEO. I understand security policies could be an issue, as well as glaring vulnerabilities.
Since they can only run this on a single device I don't know that jws would be the right solution. I haven't used it but based on what I've read it doubles as a distribution method (which we don't want). If it were to be jws then it would have to some how have to recognize the device we provided them to ensure it is being placed on the appropriate hardware, possibly based on the serial # (which I don't believe you can get from the browser).
Additionally, the browser would call methods and pass arguments to the application.
Is this even possible? If so, what tool would you recommend? Again, I'm only the messenger for this terrible idea.
You probably have Chrome or Safari configured to handle http://<uri> URIs, but many other types exist. Have you ever seen custom URI schemes used like itunes://<uri>, steam://<uri>, or skype://<uri> ?
Just like for http, when your OS tries to fetch the resource, it will attempt to handle the request in the application that registered a handler for that scheme.
If that's the kind of thing you're looking for, this question has already been answered.
My suspicion is that you were unaware of the term. If that answer works for you, we can mark this question as a duplicate.
In complement to #naomik's answer (which I believe is the right one), there are projects like AppJS, Fluid or Electron which are pretty much willing to bring web based apps to the desktop.
For the matter of communicating the App and your browser (should I say your server?), you could use an approach of message queues and websockets to get there, surely, it is a huge effort of orchestration and workarounds but in the end it is possible to get you there.
(Posted on behalf of the OP).
This does not appear to be possible. If you are considering this please don't, there are better solutions. I have finally convinced my CEO to use Angular2 inside electron for example.
Some people have asked similar questions about protecting HTML5 apps and protecting freemium apps, but not both together. I'm asking this separately because I have the impression (whether right or wrong) that HTML5 is particularly insecure vs native.
I'm working on an embedded HTML5 app I want to monetize using the freemium model, but I'm worried about how to keep its virtual currency and scoring variables from being too easily messed with by the end user, as I fear this could negatively impact revenue if some hacker (no offense intended by the term) were to create a YouTube video or blog posting about an exploit. I think it is pretty unlikely early on for this to happen, but I think vulnerability will matter more with popularity. I'm also worried about with which someone can copy an app.
I though realize both are possible inherently with an app installed on the device.
My questions are:
How easy is it, in your opinion or experience, to mess with an
unobfuscated embedded (not browser dependent) HTML5 app and its Javascript vs a native app with core files based on Java or Objective-C data?/How well does obfuscation work on HTML5 apps vs native obfuscated
apps in terms of data protection?
How difficult is it to obfuscate an HTML5 app vs using something like Proguard on regular Android apps?
Does obfuscation cause HTML5 to noticeably slow down for normal users?
Lastly, do you think it's practical to have an HTML5 app with
freemium features? Or do you personally think it is too vulnerable?
What I'm basically trying to figure out with them is whether HTML5 is particularly vulnerable or hard to protect, at least when compared to protecting native apps. If an obfuscated HTML5 app is as secure or insecure as a regular app, then I guess I'm okay with it.
The only way to prevent cheating (and unlocking freemium items is a kind of cheating) is to move all the relevant game logic to the server. Forget about obfuscation. When it's executed on the clients machine, it's under the control of the user. Obfuscation can slow the user down, but it can't stop someone who is determined to hack it. This doesn't just apply to javascript, it applies to every game client, no matter what programming language it is written in.
A general rule of designing cheat-proof multiplayer games is to never trust the client and do all calculations which are relevant for gameplay on the server.
In my opinion it is better to obfuscate AND never trust the client.
Not only that, I would even compress the obfuscated code and I would add an obfuscated decompressor in the client and/or the server.
The technique is viable and it is what professional companies are using all over the web.
Now, to answer your questions:
It's not easy to mess with a correctly obfuscated code (something
which will require you to compress/crypt even numbers).Professional
hackers won't mess with your code "for sport" unless they're given
money to do so and even in that case, they'll have a hard time doing
it (that's why I don't believe in the "forget about obfuscation" way
of thinking).
Obfuscation works really well in terms of data protection.Your code
becomes unreadable and, to some extent, it can be seen as a
compression algorithm thus it reduces file size and loading times.
Obfuscation is easy if you rely on professional tools which can
obfuscate, for example, JS, html5, css and php all together. It's
harder only if you have to develop such tools.But there exists
open-source software too in the field.
It slows down "normal users" definitely, they feel lost in front of
you code.
It's practical to have an HTML5 app with freemium features but it
all depends on your implementation of such options.
If done correctly as stated above, it's less vulnerable but,
personally, I don't like this business model.
I keep hearing about HTML5 applications. When they say that, do they mean applications that are built using HTML5, CSS3, and Javascript only and without the help of MySQL, PHP and other backend tools?
Most of the web applications are 3 tier that means heart of application is Business Logic. And I don't think any Business will get ready to write business logic in HTML for security reason and there are many more such reason like code reliability,maintainability come into picture. So no one can remove use of back end languages.
"HTML 5 Application" is whishy-washy marketing speak. It might mean something that stands alone (probably using non-HTML 5 APIs such as web storage), it might mean something that just uses a little bit of HTML 5.
Certainly you still need a server if any data needs to travel beyond the browser (e.g. to share data with other people / devices, back data up on the cloud, get news feeds, etc).
I really need your help with this. We are planning on developing a real-time web application. We look at different libraries and concepts and a little confused.
What we need is: clients connect to websites and send data(usually an integer + client machine name) whenever they want (usually 1-5 seconds). Also, the same clients must receive data(the data received from other clients) from the server in a real-time mode. (maximum 0.5 seconds). Also, this data must be stored in the database.
We were thinking about using different technologies, but cannot decide which one to use.
We need this web application to be supported on Iphones and Android Phones (maybe blackberry).
and, of course desktop browsers.
Pooling seems not a very good Idea in this situation, due to highloads.
Html 5 web sockets kinda new, and probably not supported by all browsers.
Have anyone used nodejs ?
or twisted matrix: http://twistedmatrix.com/trac/?
or orbited(cannot post more than one link)?
or tornado?
Or XMPP(Jabber. I did not find good examples.)?
or something else?
What technology is the best to use in this type of project? Also, we would probably prefer the technology that has some community support and free to use.
Thanks a lot!
There is a lot of things to consider here. I would say that HTML 5 is not an option, simply due to support across platform.
Running with NodeJS is most likely possible, but the communication methods are really complicated. Pushing data to a page isn't really something that HTML/web apps are designed to do....
To get a valid answer you are going to need to get someone to come in and sit with you to really iron out details and implementation.
When you say that clients "connect to a website", do you really need it to be a website? It sounds like all the client is sending is a number and for that you don't need a website. Just pick the language of your choice, open up a socket, and go from there.
Are you streaming data to be visualized? You might want to take a look at graphite (and/or "pyped" which is part of graphite).
What kind of data? What is the purpose?
For real-time you're not going to get a web site unless you use some type of RIA but even then, it isn't going to be enough. Services aren't going to be good enough either. You're going to end up doing some type of polling which will only ever be psuedo-real-time unless you do duplex mode which wont be supported on most of the platforms you want to support.
sockets are the way to go but that requires a client for each platform you want to handle. Maybe you should rethink your requirements.
This question is for web developers and architects.
How do you think is it a good or bad idea to have a website where you're able to edit all the templates (HTML, CSS, JS, images..) right from the admin panel?
In this case if you update website often, you don't need to search for a local version of your website on you development machine, search for a specific page, make modifications, commit it to source control server, make deployment.. Instead, all you need is just right click on the page or any element on this page, click Edit, update a piece of HTML and click SAVE - 30 seconds maximum - all from your browser ;)
You still can have version control system with this approach and rollback any template which was modified by mistake by 2 mouse clicks on a website.
I personally like this approach and need to know your opinion. So what do you think?
Note, we are talking about big websites which have to be updated often, multilingual ones etc.
Realworld web-applications which use this approach:
Wordpress
vBulletin
Personally, I think it would depend on the complexity of the website.
What you're talking about here is directly editing the structure (and potentially behaviour) of a live website. Sure, it may take longer to make the changes on your development server before rolling them out but if there's any chance of breaking either the appearance or functionality of the site then I'd think definitely think twice.
You shouldn't be allowed to modify the entire layout of your site through the site itself in my opinion. The reasons being the lack of version control and the inability to preview what you are doing, which translate into the inability to come back to an older version. Plus if you modify it locally, you are allowed to make errors that break everything, a luxury you can't always afford if you're doing it directly through the website.
Being able to add/remove content through the website is great though, it would be very painful to update a blog by modifying your HTML each time!
I once created a site that did exactly that. (Well, without any option for source control - had to learn that one the hard way...) Looking back at what I did there, a few things come to mind:
It was a traditional website with information about my sports club, that only changed occasionally, not a web app in the modern sense.
I wanted to be able to apply fixes even though I had no access to my dev machine (because it was a private project, I was at work, and ftp connections were not allowed by the comapny proxy).
For those specific reasons, the approach was a good solution. Today I would use one of the many good frameworks for this purpose (Joomla, Drupal etc) instead of coding it myself.
On important item: I was able to edit the pages that were used to generate the main site, but not the generation program or my admin pages. For those, I had to use my dev machine and upload file changes by ftp.
I think it is a good approach, if done correctly (my implementation certainly wasn't)
Editing HTML/CSS/JS files through your web browser can make things easier, as long as the editing implementation is neat, organized, idiot-proof, and keeps track of revisions.
A major issue to consider is security. The inability to modify actual files from the content management system in most software packages is a security precaution.
Learn to use a version control system effectively and efficiently. Tools like git or bzr can take care of a lot of the tedious stuff automatically, like package building, uploading, etc.
I hate it. Web development, much like the web servers themselves, shouldn't be "comfortable". Web development should be a mother gentle caressing scary experience. It should sound, look, even taste dangerous.
Neophyte web developers should be put through their paces learning the subtler aspects of their chosen text editor before they are even allowed to open a web browser; and not be allowed near a graphical web browser before 6 months of working only using lynx for debugging.
Laziness is our bane. No more, I say.
Edit: This is, perhaps, a bit tangential to the issue at hand. It should also be mentioned that visual identity that is too simple to change will change too often, leading to confused and frustrated users.