Group items matching

in title, tags, annotations or url

Great insight into Adobe AiR and the transition from browser based surfing to web application building.

Building the Dojo Toolbox allowed us to dive into Adobe® AIR™, and to create a blended toolchain of JavaScript, PHP, Python and Rhino (JavaScript on the Java Virtual Machine) for developing an amazing desktop application using open web technologies. One of the most noticeable things you'll see when moving from typical browser-based development to AIR is that you only have one browser to worry about. Dojo does a great job of masking browser JavaScript API differences, but there are still enough differences in CSS and other aspects of application development that it is somewhat refreshing to only have one platform to develop again. Also, since AIR includes WebKit, it has one of the fastest JavaScript implementations around and offers numerous useful experimental CSS properties that you can use in the AIR context. Apple has invested a lot in WebKit development, and AIR will naturally inherit those benefits when they next upgrade the included WebKit.

"By combining unified communications, IM, SharePoint, and blogs and wikis while protecting its IP, Monsanto is advancing teamwork." InformationWeek has posted a number of technology innovation-implementation profiles. Monsanto is one of the best "collaborative" examples, although it's very similar to the model GE presented at Office 2.0. These colalborative concepts go back 1998, and the early work Ars Digita was doing with the first "Knowledgeware" - wiki applications. The first "use case" to be published was that of the global electronics giant, Siemanns. Notice the SharePoint - MSOffice integration as a key element in the Monsanto collaboration strategy. That connection "forced" Monsanto to rebuild their document databases and portals using SharePoint and SQL Server.

The author clearly missed that Sun is a full-fledged Microsoft partner and that StarOffice 9, of all OpenOffice.org clones, is the only one that has write support for both ODF v. 1.2 and ODF v. 1.1, the latter of which is the only ODF version being implemented by Microsoft. The other OOo clones write only to ODF 1.2, which is dramatically different from ODF 1.2. So StarOffice will almost certainly have better interop via ODF with MS Office 2007 than will OOo 3.x or Lotus Symphony. For $25 per seat in the enterprise, $34.95 retail. The author simply misses that "pretty much the same thing can [NOT] be had for nothing from OpenOffice.org." There is a method to the claimed Sun madness, methinks. IBM gets left standing at the altar again.

"...some browsers and plug-ins were adopting storage-related API's that are a part of the new HTML5 draft specification. While Gears, Opera and Webkit have implemented structured storage API's, the remainder of the HTML5 spec currently remains mostly unimplemented and also in a state of flux. HTML5 is a super-sized effort to bring all the browsers under a single, standard markup language and set of API's - but with Microsoft, Adobe and others racing ahead with their own next-gen web technologies, will we ever see a real HTML5 standard?" This article was posted in August of 2008, before the surprise release of the WebKit based "Google Chrome" .... the WebKit RiA alternative to Adobe AiR and Microsoft Silverlight

Microsoft's proposed undertaking for resolving the ECIS complaint to the European Commission regarding its office productivity software can be downloaded from this linked web page. I've given it a quick skim. Didn't see anything in it for anyone but competing big vendors. E.g., no profiling of data formats for interop of less and more featureful implementations, no round-tripping provisions. Still, some major concessions offered.

Google "Rich Snippets" is a new presentation of HTML snippets that applies Google's algorithms to highlight structured data embedded in web pages. Rich Snippets give end-users convenient summary information about their search results at a glance. Google is currently supporting a very limited subset of data about reviews and people. When searching for a product or service, users can easily see reviews and ratings, and when searching for a person, they'll get help distinguishing between people with the same name. It's a simple change to the display of search results, yet our experiments have shown that users find the new data valuable. For this to work though, both Web-masters and Web-workers have to annotate thier pages with structured data in a standard format. Google snippets supports microformats and RDFa. Existing Web data can be wrapped with some additional tags to accomplish this. Notice that Google avoids mention of RDF and the W3C's vision of a "Semantic Web" where Web objects are fully described in machine readable semantics. Over at the WHATWG group, where work on HTML5 continues, Google's Ian Hickson has been fighting RDFa and the Semantic Web in what looks to be an effort to protect the infamous Google algorithms. RDFa provides a means for Web-workers, knowledge-workers, line-of-business managers and document generating end-users to enrich their HTML+ with machine semantics. The idea being that the document experts creating Web content can best describe to search engine and content management machines the objects-of-information used. The google algorithms provide a proprietary semantics of this same content. The best solution to the tsunami of conten the Web has wrought would be to combine end-user semantic expertise with Google algorithms. Let's hope Google stays the RDFa course and comes around to recognize the full potential of organizing the world's information with the input of content providers. One thing the world desperatel

Sun takes on the problem of interoperability and portability of applications in a world where there will be many many clouds. At the roll out of the Sun Cloud, key executives explain Sun's implementation of Open Cloud API's and what they see as a pressing need for management tools that will allow some standardization across clouds.

Sun's Open Cloud API plan is a clean reuse of existing Open Web API's.

"..... The underpinning of the Open Cloud Platform that Sun will be pitching to developers is a set of cloud APIs, the creation of which is focused under Project Kenai and which has been released under a Community Commons open source license. Sun wants lots of feedback on the APIs and wants these APIs to become a standard too, hence the open license. These APIs describes how virtual elements in a cloud are created, started, stopped, and hibernated using HTTP commands such as GET, PUT, and POST...."

"...... The upshot is that these APIs will allow programmatic access to virtual infrastructure from Java, PHP, Python, and Ruby and that means system admins can script how virtual resources are deployed. The APIs, as co-creator Tim Bray explains in his blog, are written in JavaScript Object Notation (JSON), not XML. The Q-Layer software is a graphical representation of what is going on down in the APIs, and you can moving virtual resources into the cloud with a click of a mouse using the dashboard or programmatically using the APIs from those four programming languages listed above. (PHP support is not yet available, but will be)....."

I can see why Sun picked those four languages first. Can I assume that with a bit of work, this API will be usable from any language with a C "foreign function interface", such as Perl, Common Lisp, Bourne shell, Squeak Smalltalk, and others that your server application might be written in?

I read this comment that largely answers my question at: http://www.tbray.org/ongoing/When/200x/2009/03/16/Sun-Cloud "So right now JSON out of a shell tool is not so good. More things like this will create pressure for development of tools to change that, but years of widespread XML/HTML deployment have only produced a few oddly maintained tools. Perhaps that's because you can scrape quite a bit of the web with a couple sed passes, and if I were to have to deal with the mentioned tools, that's probably the route I'd take." (seth w. klein) In other words, with a bit of work, _anything_ that can talk text over HTTP can do this with a bit of work, but an object-oriented is likely to be more at home with JSON (JavaScript Object Notation)

Joel takes on the difficult issues of standards and vendor specific implementations. This is a classic!

"The purpose of this project is to implement a set of administrative applications, user level applications and supporting framerks using GNUstep and for GNUstep. These applications create together a workspace or desktop environment. Our goal is for each application, tool or framework, if possible, to: support maximum portability to all GNUstep supported platforms, including Windows create a corresponding Cocoa/Mac port: this is very useful for many applications that are then available natively on Mac and helps testing and comparison of the application against Cocoa support of the widest range of compiler versions, minimum dependency requirement allow the usage without requiring other GAP framework and applications or, if, a minimal set of them"

Get ready to fight TPP fast-tracking in member states. see also 'Wikileaks' free trade documents reveal 'drastic' Australian concessions.' Source: The Guardian. http://goo.gl/hicb5h Remember that in the U.S., only Senate ratification is required. The measure will not go before the House before implementation. 

"Writing software is too hard and it takes too long. It's time for a new way to write software - especially application software, the user-facing software we use every day to talk to people and keep track of things. This new way should be radically simple. It should make it possible to build a prototype in a day or two, and a real production app in a few weeks. It should make everyday things easy, even when those everyday things involve hundreds of servers, millions of users, and integration with dozens of other systems. It should be built on collaboration, specialization, and division of labor, and it should be accessible to the maximum number of people. Today, there's a chance to create this new way - to build a new platform for cloud applications that will become as ubiquitous as previous platforms such as Unix, HTTP, and the relational database. It is not a small project. There are many big problems to tackle, such as: How do we transition the web from a "dumb terminal" model that is based on serving HTML, to a client/server model that is based on exchanging data? How do we design software to run in a radically distributed environment, where even everyday database apps are spread over multiple data centers and hundreds of intelligent client devices, and must integrate with other software at dozens of other organizations? How do we prepare for a world where most web APIs will be push-based (realtime), rather than polling-driven? In the face of escalating complexity, how can we simplify software engineering so that more people can do it? How will software developers collaborate and share components in this new world? Meteor is our audacious attempt to solve all of these big problems, at least for a certain large class of everyday applications. We think that success will come from hard work, respect for history and "classically beautiful" engineering patterns, and a philosophy of generally open and collaborative development. " .............. "It is not a

"How do we transition the web from a "dumb terminal" model that is based on serving HTML, to a client/server model that is based on exchanging data?" From a litigation aspect, the best bet I know of is antitrust litigation against the W3C and the WHATWG Working Group for implementing a non-interoperable specification. See e.g., Commission v. Microsoft, No. T-167/08, European Community Court of First Instance (Grand Chamber Judgment of 17 September, 2007), para. 230, 374, 421, http://preview.tinyurl.com/chsdb4w (rejecting Microsoft's argument that "interoperability" has a 1-way rather than 2-way meaning; information technology specifications must be disclosed with sufficient specificity to place competitors on an "equal footing" in regard to interoperability; "the 12th recital to Directive 91/250 defines interoperability as 'the ability to exchange information and mutually to use the information which has been exchanged'"). Note that the Microsoft case was prosecuted on the E.U.'s "abuse of market power" law that corresponds to the U.S. Sherman Act § 2 (monopolies). But undoubtedly the E.U. courts would apply the same standard to "agreements among undertakings" in restraint of trade, counterpart to the Sherman Act's § 1 (conspiracies in restraint of trade), the branch that applies to development of voluntary standards by competitors. But better to innovate and obsolete HTML, I think. DG Competition and the DoJ won't prosecute such cases soon. For example, Obama ran for office promising to "reinvigorate antitrust enforcement" but his DoJ has yet to file its first antitrust case against a big company. Nb., virtually the same definition of interoperability announced by the Court of First Instance is provided by ISO/IEC JTC-1 Directives, annex I ("eye"), which is applicable to all international standards in the IT sector: "... interoperability is understood to be the ability of two or more IT systems to exchange information at one or more standardised interfaces

"DRAFT REPORT on the implementation of Directive 2001/29/EC of the European Parliament and of the Council of 22 May 2001 on the harmonisation of certain aspects of copyright and related rights in the information society (2014/2256(INI))"

It seems the U.S. is not the only nation that has liars for head of state. 

"A W3C (World Wide Web Consortium) mailing list post entitled "HTML6 proposal for single-page Web apps without JavaScript" details the proposal, dated March 20. "The overall purpose [of the plan] is to reduce response times when loading Web pages," said Web developer Bobby Mozumder, editor in chief of FutureClaw magazine, in an email. "This is the difference between a 300ms page load vs 10ms. The faster you are, the better people are going to feel about using your Website." The proposal cites a standard design pattern emerging via front-end JavaScript frameworks where content is loaded dynamically via JSON APIs. "This is the single-page app Web design pattern," said Mozumder. "Everyone's into it because the responsiveness is so much better than loading a full page -- 10-50ms with a clean API load vs. 300-1500ms for a full HTML page load. Since this is so common now, can we implement this directly in the browsers via HTML so users can dynamically run single-page apps without JavaScript?" Accomplishing the goal of a high-speed, responsive Web experience without loading JavaScript "could probably be done by linking anchor elements to JSON/XML (or a new definition) API endpoints [and] having the browser internally load the data into a new data structure," the proposal states. The browser "then replaces DOM elements with whatever data that was loaded as needed." The initial data and standard error responses could be in header fixtures, which could be replaced later if so desired. "The HTML body thus becomes a templating language with all the content residing in the fixtures that can be dynamically reloaded without JavaScript." JavaScript frameworks and JavaScript are leveraged for loading now, but there are issues with these, Mozumder explained. "Should we force millions of Web developers to learn JavaScript, a framework, and an associated templating language if they want a speedy, responsive Web site out-of-the-box? This is a huge barrier for beginners, and right n

" Ernesto on January 22, 2016 C: 47 Breaking Copyright holders want websites to implement strict filters to guarantee that content stays down after a DMCA notice is received. The EFF warns against these demands, arguing that they will lead to a "filter everything" approach. According to the EFF this will result in more abuse and mistakes from often automated takedown bots. "

"Centralized Management Open Source solution for small-to-large Disaster Recovery implementations using ReaR."