![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
I will use today being Christmas and me being on vacation as an excuse not to fight the hard fight of ordering my thoughts into a linear, nicely reading blog post. So here's an unordered list of my thoughts presented as an ordered list only to allow for easier commenting. They do form a picture, however.
- Drupal 7 is a roaring success. Check the usage numbers, in a single year there are about 75% as many Drupal 7 sites as Drupal 6 and D6 is very slowly dwindling. Within 18 months of Drupal 7 launch, Drupal usage overall will double.
- We can conclude people are happy with what and how you can build with Drupal 7. I can attest to this. It's fantastic to build a site with D7.
- The famous Web is dead Wired article is slightly misleading, check what the chart is about: it's a proportion of traffic and the web standing at 50% of the video traffic in fact means an exploding web market not a dying one (video is a lot of bytes).
- Apps are not the future, HTML5 is. See article about the Financial Times going that route or this article about how a mobile website gives a branding effort better bang for the buck.
- We have a great platform to build webpages: Drupal. We are making it HTML5 as we speak.
- If one wants to build a great platform where you can create a web site in the UI it means abstractions. Abstractions need code. Making that amount of code speedy is a formidable challenge.
- PHP sucks anyways for speed. Just compare it with an evented stack.
- However, we can push or pull content into a speedy stack and use that to answer AJAX fast.
Commenting on this Story is closed.
It makes no sense for Drupal to push or pull anything... that job is better left off to other frameworks that are lighter with much less cruft.
Further, abstractions not targeted at developers are harmful to developers as they let all sorts of incompetent people into the mix... Further they make arbitrary tasks more difficult as you are now expected to interact with some ugly ui to achieve your goals. Then you have to go into code and interact with some hideous api to change what this ugly tool has produced to do exactly what you want to do. This also makes deployment a mess.
What should happen is that the API should be targeted at developers and the ugly UI for hacks should be left out... so as not to invite them to the party.
If you want to do something, you do it in code or not at all. That way everyone is not calling himself an engineer.
And yet Salesforce succeeds
I think the main problem with the "either/or" approach in absolutely anything is the sheer reduction in scope. API-only designs make a programming job easier, while UI-only designs make dynamic management easier (yes, this "easier" is debatable). They both appeal to engineers, but neither appeals to the end user, who doesn't want to deal with anything.
A properly flexible architecture is centered around everything (or not centered around anything as one might say). Of course, designs get expensive, but if one isn't willing to consider the perspective of both API and UI designs then one shouldn't really isolate and criticize either of them.
API is API; UI is UI. They are on different levels of abstraction and should be treated as such. Thus, designing a UI with a pseudo-architecture to produce "crap" at the API level is just bad design -- for both the UI (doing what it shouldn't) and the API (for being incomplete for the UI to even attempt what it missed).
If you follow that line of thinking, you probably shouldn't be using Drupal at all, let alone writing long winded complaints about it.
Going lower level than HTML is important. For one thing, it allows us to assemble a page from more than one installation. That opens the door to things like federated social web, federated drupal content and functionality (baked into core of the entire install base no less), compatibility layers, different admin clients, staged migrations - that's just a few.
hi chx,
thanks for your nifty redis_ssi module!
whilst a leaner bootstrap (and non-fapi-based apis) are needed to make drupal more of "a first-class" citizen in a polyglot, distributed environment, i think that pushing & pulling certainly is already possible and certainly not outright impossible :)
i've been working on some nodejs-drupal integration and started two sandboxes[1} for dnode-integration[2] and pubsub/cometd[3] (using the lovely faye[4] library). This allows for complementing server-side strategies (ssi) and polling AJAX with pubsub-techniques and "client-side-includes" that allow changes to content/blocks/views to be broadcast to all clients with minimal overhead, complexity and latency. i hope to blog about it (and integrate it with e.g redis_ssi) after the christmas
best, frega
ps. it's a bit finicky to install node, dnode, dnode-php and dnode but the README.txt[5] provides an example of how to setup client-side-includes for anonymous users and also an example on how to use a "broadcasting" views-cache plugin.
[1] http://drupal.org/sandbox/frega/1321342 /
[2] dnode for nodejs: https://github.com/substack/dnode php-implementation: https://github.com/bergie/dnode-php
[3] http://drupal.org/sandbox/frega/1357240
[4] http://faye.jcoglan.com/
[5] http://drupalcode.org/sandbox/frega/1357240.git/blob/HEAD:/README.txt