Skip to main content

Home/ In-the-Clouds-with-SOA-XML-and-the-Open-Web/ Group items tagged yahoo

Rss Feed Group items tagged

Gary Edwards

Yahoo BrowserPlus™: Web 3.0 - 0 views

  • BrowserPlus™ is a technology for web browsers that allows developers to create rich web applications with desktop capabilities.
  •  
    Another JavaSript library concept, but this time secure. Not as robust as jQuery, but Yahoo is off to a great start. wikiWORD could use this for dynamic page generation.
Gary Edwards

The Enterprise- Cloud Duo: SOA plus WOA | Dana Gardner - 0 views

  • Cloud providers and mainstay enterprise software vendors could make sweeter WOA plus SOA music together. They may not have a choice. If Microsoft acquires Yahoo!, there will be a huge push for Microsoft Oriented Architecture that will double-down on “software plus services.” And MSFT combined with Yahoo would have an awful lot in place to work from — from the device and PC client, to the server farm, business applications, developer tools and communities, and ramp-up of global cloud/content/user metadata resources. I think Microsoft already understands the power of WOA plus SOA.
  • The cloud that can manage data in way that allows both user-level and process-level access, with granular permissioning — and allows CXOs to feel good about it all — gets the gold ring. The cloud business is a 50-year business.
  •  
    Review of Dion Hinchcliffe's article, "Web 2.0 driving Web Oriented Architecture and SOA".
Gary Edwards

BOOK Offered Or Kept: Digital reading without Epub? | TeleRead: Bring the E-Books Home - 0 views

    • Gary Edwards
       
      .wiki is the native wikiWORD language for MSOffice "editors". It's really AJAX for documents, with HTML+ handlign the "structure", and CSS+ handling the "presentation". We need javascript to perfect the full range of typographical options used by knowledge workers makign their way from MSOffice to the web. BOOK is a good place to start.
  • The structure of a BOOK would look like this: …BOOK/ ……index.html ……images/ ………cover.png ……css/ ………base.css ………skins/ …………modern.css …………classic.css …………nouveau.css ……scripts/ ………prototype.js ………base.js ………extensions.js
  • As for the Javascript, it’s based on the ECMAScript standard, which has evolved into a strongly-typed, object-oriented programming language and is one of the few web “standards” which really is a standard. BOOK authors will welcome the addition of a scripting language, as it is NOT currently supported in the IDPF specifications. In fact, it’s forbidden for .epub reading systems to execute scripts. It’s also forbidden for them to display a file called index.html without first loading and parsing several other files.
  • ...10 more annotations...
    • Gary Edwards
       
      Good point! The IDPF ePUB format does not support javascript! Which makes "BOOK" a better format to target.
  • EPub is an excellent, high-fidelity format for both direct rendering and for user-side conversion to other formats for particular platforms such as very limited resource handheld devices.
  • Jon Noring Says:
  • For BOOKs, it offers true pagination, typesetting, skinnable and collapsible layouts, footers and headers, footnotes as popups, inline text, true footer notes, or endnotes . . . the list goes on. YUI, JQuery, dojo, MooTools, and Prototype are just a few of the frameworks available, and they’ve been addressing these issues for some time now.
  • Javascript is useful mainly for rendering, not bells and whistles. Without Javascript, the non-normalized implementations of CSS out there become useless–you can’t rely on them to produce a consistent rendering of a document. Unfortunately, with CSS3 the rendering game is only going to get more complicated. I don’t advocate executing scripts from epubs, I advocate executing scripts in epub reading systems. Two very different things, as you’re aware.
  • Scripting is *essential* for many digital publishing projects and not understanding it is a major failure of IDPF. Saying that “we will reconsider scripting when adoption of epub grows” is also inadequate, because nobody will wait patiently, but will choose some another platform for their publishing needs, Adobe AIR for example.
  • My criticism of epub is not about details but about its fundamentals. It seems to me that while preparing the spec the most fundamental question was left out of view: what is the right model for digital publication: is it a physical book? Or is it something else? If something else, then what? From my point of view, not a physical book, but a website should be thought as the right model. Why website? - because of the well supported and ubiquitous mix of technologies (html, css, javascript) and because of the workflow (publishing early versions of the publication on the website for gathering feedback and then publishing as downloadable file). If a model for a digital publication is a website, then any format which does not allow to have everything which we have on websites and does not allow to take all website’s html, css and client-side scripts and publish them as downloadable file without much changing them, is doomed to failure in the long run. It seems that epub is now on this way to failure.
  • What I’d like to see is a sort of epub spinoff, another specification from the IDPF, if you will, with slightly different requirements. Instead of BOOK, we could call it epub-lite. The basis for this simplified, consumer-oriented version of .epub would be the same browser-centric building blocks under the IDPF specs. The difference would be in the file structure and in the way a browser deals with it.
    • Gary Edwards
       
      What we really need are "webDOCS". Laisvunas is absolutely right. The web is the target, with print and device "flow" an auxillary offshoot. I think we can have it all, and Aaron's "BOOK" is a good place to start. My thinking though is that javascript has to come from standardized libraries such as jQuery or Yahoo's "BrowserPLUS". Yahoo BrowserPLUS does have a security model and off-line capability built in. It's nowhere near as robust and sweepign as the jQuery javascript library, but i don't see why the two can't be combined. Good thinking on the part of Laisvunas!
  • What I wish for is this: a simple ebook format which allows me to use all technologies there are on the web with exactly the same freedom as on web and imposing no additional limitations. Secondly, some browser-based reader (browser add-on or some program based on some quality browser engine). Thirdly, some program (editor/compiler) for producing publications from preexisting web-pages.
    • Gary Edwards
       
      Once again Laisvunas nails it. I really like his "AIR" suggestion. It's also true that flowing content ready device browsers like the webKit "Safari" and SkyFire will be far more widespread than any ePUB reader!!!!! So why not write for both the web and the device at the same time?
  • The system I’m referring to is alive and well at bookglutton.com. It features an AJAX reader and Package Creation tool. The package tool is currently part of the upload feature which enables people to convert .doc, .rtf, and html documents to epub packages that can be viewed in the Reader. Once we have more epubs out there, direct epub upload will also be an option. We may also eventually enable epub download. Right now, we’re having some doubts about the value of that.
    • Gary Edwards
       
      How about "eWEB" as a format name? Is it better than "webBOOK" or webDOC"?
  •  
    Aaron Miller writes about the limitations and difficulties with ePUB. He suggests a new format, "BOOK" based on ePUB but web ready. BOOK is an AJAX format in that it includes (X)HTML, CSS and JavaScript! Excellent stuff! The discussion on this page is one of the best on the Web. ePUB gets thrashed, but with arguments very difficult to contest. The web is everything, and Aaron's friends fully understand this. Sadly, the ePUB crowd does not. I found this site looking to solve the problem of numbered lists in ePUB.
Gary Edwards

Microsoft Says Yes With Mesh While Google Waits On Officenomics - 0 views

  • Imagine (not for long will it be ephemeral) an information bus that orchestrates the signaling of text, rich media, calendar, communications, transaction, and group location status under a social graph umbrella based in part on user-controlled behavior aggregation (gestures). Now imagine what Google needs to do to match this architecture and its overwhelming lead in connectors to existing hardware via Windows. Google’s answer for now is no. There’s no need to attack Mesh directly, but rather continue to iterate on Officenomics while retaining its dominant leads in user credibility and advertiser cloud. But Microsoft can efficiently hybridize Google and other microbig services with the Mesh layer added, creating information bus fail-over to multiple streams (virtual devices) to insure enterprise levels of reliability and security.
  •  
    Techcrunch review of a recent Gilmore Group interview with MS Live Mesh product manager
Gary Edwards

A reminder of why Microsoft wanted Yahoo | Tech news blog - CNET News.com - 0 views

  • When Windows has a real rival, Microsoft has real problems. As Blodget notes, there are caveats: The unofficial Office monopoly should give Microsoft breathing room for a few more years. But even that could be threatened as Google's more-affordable Web applications improve. This storm has been gathering for years. In 2005, we wrote a piece at News.com about Google's longterm threat to Microsoft. The impetus was a major management shuffle at MSN, but we had fun pulling out some old Microsoft memos about now-defunct Netscape in the early days of the World Wide Web. My favorite was a note written in 1995 by Microsoft engineer Ben Slivka describing a "nightmare" scenario for his company. "The Web...exists today as a collection of technologies that deliver some interesting solutions today, and will grow rapidly in the coming years into a full-fledged platform (underlined for emphasis in the original memo) that will rival--and even surpass--Microsoft's Windows," Slivka wrote. Microsoft didn't pay too much attention to the warning. Ten years later, another internal memo put a name to that nightmare--Google. Now Blodget has advanced that nightmare scenario a few more steps with his analysis.
  •  
    Review of Henry Blodgett's predicitve analysis that within the next year Google's search revenue will surpass Microsoft's revenue from Windows. MS still has MSOffice and the Exchange/SharePoint/SQL Server juggernaut. But Blodgett fearlessly predicts the beginning of the end fo rthe great monopolist. Great quote from Microsoft's Ben Slovika.
Gary Edwards

'Enough with WOA, stick to SOA,' say IT architects - I say drop WOA and SOA | Dana Gard... - 0 views

  • So, true, WOA, isn’t an architecture, it’s a webby style of apps and integration, of mashups and open APIs, of using REST and RIA clients, all from a variety of Internet sources. It’s integration as a service, too. These can all be composited, accessed and managed by an enterprise’s internal SOA, or not. The services can come from a cloud, public or private. Forrester says the growth curve for Enterprise 2.0 is steep, but I think it will be even steeper. These webby assets could just as well come together as portals, standalone Web apps, SaaS, or RIA front ends for composited ecology services that support extended enterprise processes. The point is there’s no need to wait.
  • rapid ramp-up of services hybrids — of public/private clouds, services ecologies, internal and external hosting, social enterprise media tools, mashups in myriad forms, integration of services regardless of origins or types of aggregation. You can today begin a business online and scale it without an IT department, or an on-premises datacenter. You just can.
  • The fact is that the definitions of and distinctions between applications, platforms, services, tools, clouds, portals, integration, middleware are — all up for grabs. IT as a concept is up for grabs. The shifts in the software arena at that disruptive. It’s why Microsoft is seeking to buy Yahoo, and not Oracle.
1 - 6 of 6
Showing 20 items per page