Mood:

Now Playing: Flaming Furries - Skunks get too close to basement furnace and become frantic stink bombs (awful scenes)
Topic: Growth Charts
Did you ever get through with a conversation and say "gee, I wish I had said..."? Well, the Yahoo posting forum format doesn't allow for much follow up because, when you do follow up, those who don't want you to read can easily bury the comments with their own innane postings.
So, if you can't stomach reading the Yahoo VCSY board (believe me. more sympathetic I could not be.), I thought you might need to see the MVC discussion from Yahoo put in a more capsulated view.
Therefore, I'll chop and paste my words of relevant revelation to the heathen who rage too much.
PLUS, there are things I wanted to say after I had already posted there, so these posts distilled into this post will also have additional verbiage by me and some editorial corrections (also by me - it's all about me, me, me.).
Concerned about authenticity and purity? Read the Yahoo posts associated with the timestamps to see just what is new and what is old.
So, (just imagine you've dropped into the middle of a conversation).
begin thread: http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_V/threadview?
m=tm&bn=33693&tid=4155&mid=4155&tof=5&rt=1&frt=1&off=1
pick up @ 14-May-08 02:37 pm
portuno: Can ANYBODY tell us what is "gibberish" about the claims in 744?
http://www.google.com/patents?vid=USPAT6826744
sw_mail: Yes, 744 is a framework that implements the MVC design pattern, first described by Trygve Reenskaug in 1979. Yet, 744 is dated 2004. The facts hurt. http://en.wikipedia.org/wiki/Model-view-controller
computerguy: I'm a professional Java developer who does a lot of work with MVC in Swing GUIs. I had no idea the pattern was that old. Thanks for the link!
portuno: Notice the "professional Java developer" makes my case all by himself with the words: "does a lot of work with MVC in Swing GUIs".
We're talking about much more than a GUI model controller, "computerguy". We're talking about extending what facility and wonders MVC can accomplish with interfaces into the actual fabric and material of the elements being used to construct the applications.
Read the next post then see if you can understand where you shot whoever sent sw_mail the link before the guy even got out the door.
portuno: MVC
LOL
This is going to be good.
"In MVC, the Model represents the information (the data) of the application and the business rules used to manipulate the data, the View corresponds to elements of the user interface such as text, checkbox items, and so forth, and the Controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements."
If MVC desribes any prior art,m it is prior art already accounted for in the Siteflash patent in the discussion about content management as a prior art.
MVC
A) Model - information (the data AND the business rules - in other words the workflow)
B) View - elements of the user interface
C) Controller - activity manager between the model and the user.
Thus, an interface control mechanism.
SiteFlash
A) Content - information (the data)
B) Format (the form in which the data is presented)
C) functionality (the workflows applied to the data within the format)
Thus, an integrated application.
Very telling the list of MVC implementations is so large, yet, the patent examiner never made any reference to any of those listed. Also very telling, the list of MVC implementation is very large, yet, none of those implementations is capable of creating anything as integrated in all three facets of software construction.
If you haven't noticed, MVC forgets about the "functional program". MVC occupies the space between the modeled program behaviour and the user as an interface controller... not as a functionality integrator.
Siteflash treats the program as simply another component to be integrated with content and format. MVC assumes you already have the program crammed together with the content (and we know that doesn't work in "arbitrary" ways - precisely why all those implementations listed are proprietary programming languages and not capable of handling all components in an arbitrary fashion.
portuno: This: "In MVC, the Model represents the information (the data) of the application and the business rules used to manipulate the data, the View corresponds to elements of the user interface such as text, checkbox items, and so forth, and the Controller manages details involving the communication to the model of user actions such as keystrokes and mouse movements."
Is THAT what Microsoft lawyers are going to hang the company's future on?
So, please explain how this achieves an arbitrated framework for ANY content, ANY format and ANY functionality of an application.
You're dong what even Microsoft did in challenging this patent - you're using easily seen abstracts to blow smoke over the deeper values in virtualization and the arbitrating quality that virtualization has on the components of an application construction.
If MVC were an architecture like 744, there would BE no individual proprietary languages as listed in the wiki article. The need for the incremental refinements offered by those languages would have been swallowed up in one MVC framework capable of presenting all languages as one arbitrated field of commands.
And, if the patent examiner missed that one, you'll have to explain how Microsoft failed to adequately challenge the patent when they tried the first time.
Basically what you've got in MVC is a pattern generator. What you have in 744 is an ecology creator for full development of applications during the entire life cycle as contained in the application. The development ecology IS the application... and you can't get that out of MVC.
Nice try but it's most likely Microsoft is going to be shoveling dirt into the oncoming tide with that stance.
But, we're glad somebody out there is sending you clowns some script material. You've been sucking your own incompetence before somebody came to your rescue.
So, your turn. Demonstrate, please, precisely how and where MVC supercedes what 744 claims to do.
sw_mail: And how does the .net framework violate 744?
portuno: Did I step on your toes?
end thread.
I guess I stepped on sw_mail's fingers. Or else he's trying to find more script from some more relevant engineer.
Here's another conversation.
begin thread @ http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_V/threadview?
m=tm&bn=33693&tid=4186&mid=4186&tof=8&frt=1
pick up at 14-May-08 03:35 pm
sw_mail: And how does the .net framework violate 744?
(me: this appears to be a big question for sw_mail aka computerguy aka vcsy_is_pest).
portuno: Read this: http://www.microsoft-match.com/content/developer/net_35_sp1_changes_your_expression.html
and we'll talk later after you catch your breath.
portuno: BUT of course you really need to know software architecture and understand what you're reading both in a patent and in technical specifications.
That was just a wikipedia article about MVC but it tells the story in a basic way for laymen. Once you do some exploration, you realize why all the traditional procedural languages never advanced into the web-application arena SiteFlash and MLE/Emily occupy.
No wonder it looks "obvious". It looks almost like what they do when they build a GUI. Except, Siteflash isn't a GUI nor a GUI builder alone. SiteFlash is a developmental ecology for applications. It's a creating framework for building other creating frameworks from which operating systems and applications and, yes, even more MVC fashioned languages can be built.
The idea is that you can plug any content you have, any (what the patent is meaning when you read "arbitrary". just say "any" when you read "arbitrary" and you'll beging to see the scope. It's a virtualization platform for any content and format. In other words a Microsoft "Expression" but more. ONE OF THE THINGS Siteflash can do is to act as a content/format manager for any website you want to connect to any legacy equipment you have. BUT WAIT! Content managers or ok but it's been done before. In fact, it's what ALL there is in that "designer" discipline.
Microsoft missed a great opportunity to combine their Visual Studio's development platform with their Expression designer platform. Imagine being able to be a designer AND a developer AT THE SAME FREAKING TIME.
They didn't but SiteFlash can. So we now have the concept of a stylist who can build functionality where before, with the kind of programming environments Java Joe has at his hands, anyone that wants to build an application has to have someone to build the programming code and someone completely different building the content into a formatted web page. If the two of you work well, you can build some pretty fantastic web services - of course Microsoft is going to have to perfect their interoperable capabilities over internet. They can't even demonstrate much of it in their own proprietary ranks, much less doing that kind of thing on the web.
SiteFlash offers, at one level, precisely what any web designer would like to be able to do... without a programmer. Content, format is old hat. That's what MVC represents; automating the display of content. Call it Automatic Television. That's what Microsoft's future is going to be because they can't combine the kind of virtualization architecture to allow them to combine content and format AND functionality.
AND THAT is only the beginning.
I do appreciate the gift sw_mail gave all us VCSY longs since it's the only piece of "prior art" any skeptic has pointed to that somewhat looks like SiteFlash.
But, MVC really doesn't even look like SiteFlash once you actually read the material. And it certainly doesn't do what SiteFlash can do. Those who are passing MVC around as a "prior art" are doing an intellectually dishonest service to those they pass that idea around to, or they really do not know what needs to be done in the software construction arena to meet next-generation needs.
So, now that we know where the "prior art" is, perhaps we can have some real developers (and I mean REAL developers) study the information on the vaunted MVC methodology, then come back and give it to the 744 patent with both barrels.
Come on, guys and gals. ONE of you must have the hot sauce to argue the situation. I mean, you're all betting your careers that Microsoft doesn't need something like SiteFlash.
And, if you're open-source, you're staring at something that could strip your third-party business to the carcass very quickly.
end thread.
There's much more but I'll wait a bit to post since you're going to need time for your little eyeballs to absorb it all.
P. Douglas :
One thing I would like to know: does the author prefer using web apps over comparable desktop apps? E.g. does the author prefer using a web email app over a desktop email client? Doesn't he realize that most people who use Windows Live Writer, prefer using the desktop client over in-browser editors? Doesn't he realize that most people prefer using MS Office over Google Apps by a gigantic margin? The author needs to compare connected desktop apps (vs. regular desktop apps) to browser apps, to gauge the viability of the former. There is no indication that connected desktop apps are going to fade over time, as they can be far richer, and more versatile than the browser. In fact, these types of apps appear to be growing in popularity.
Besides, who wants to go back to the horrible days of thin client of computing? In those days, users were totally at the mercy of sys admins. They did not have the empowerment that fat PCs brought. I just don't understand why pundits keep pushing for the re-emergence of thin client compputing, when it is fat PCs which democratized computing, and allowed them to write the very criticisms about the PC they are now doing.
Posted by P. Douglas | April 30, 2008 3:50 PM
portuno :
"I just don't understand why pundits keep pushing for the re-emergence of thin client compputing, when it is fat PCs which democratized computing, and allowed them to write the very criticisms about the PC they are now doing."
Because business and consumerism sees the move toward offloading the computing burdens from the client to other resources as a smart move. That's why.
Pundits are only reporting what the trends tell them is happening.
Posted by portuno | April 30, 2008 3:59 PM
P. Douglas :
"Because business and consumerism sees the move toward offloading the computing burdens from the client to other resources as a smart move. That's why."
Why is this a smart move? If the PC can provide apps with far richer interfaces that have more versatile utilities, how is the move to be absolutely dependent on computing resources in the cloud (and an Internet connection) better? It is one thing to augment desktop apps with services to enable users to get the best of both (the desktop and Internet) worlds, it is another thing to forgo all the advantages of the PC, and take several steps back to cloud computing of old (the mainframe). Quite frankly, if we kept on pursuing cloud computing from the 70s, there would be no consumer market for computing, and the few who would 'enjoy' it, would probably be confined to manipulating text data on green screen monitors.
"Pundits are only reporting what the trends tell them is happening."
Pundits are ignoring the trends towards connected desktop applications (away from regular desktop apps) which is proving to be more appealing than regular desktop apps and browser based apps.
Posted by P. Douglas | April 30, 2008 4:21 PM
portuno :
Why is this a smart move?
"If the PC can provide apps with far richer interfaces that have more versatile utilities, how is the move to be absolutely dependent on computing resources in the cloud (and an Internet connection) better?"
The PC can't provide apps with richer processing. The interfaces SHOULD be on the client, but, the processing resources needed to address any particular problem does not need to be on the client.
The kind of processing that can be done on a client doesn't need the entire library of functions available on the client.
If your hardware could bring in processing capabilities as they became necessary, the infrastructural footprint would be much smaller.
The amount of juggling the kernel would have to do to keep all things computational ready for just that moment when you might want to fold a protein or run an explosives simulation, would be reduced to the things the user really wants and uses.
An OS like Vista carries far too much burden in terms of memory used and processing speeds needed. THAT is the problem and THAT is why Vista will become the poster child for dividing up content and format and putting that on the client with whatever functionality is appropriate for local computing.
This isn't your grandfather's thin client.
"It is one thing to augment desktop apps with services to enable users to get the best of both (the desktop and Internet) worlds, it is another thing to forgo all the advantages of the PC, and take several steps back to cloud computing of old (the mainframe)."
Why does everyone always expect the extremes whenever they confront the oncoming wave of a disruption event? What is being made available is the proper delegation of processing power and resource burden.
You rightly care about a fast user interface experience. But, you assume the local client is always the best place to do the processing of the content that your UI is formatting.
The amount of processing necessary to accomplish building or providing the content that will be displayed by your formatting resources can be small or large. It is better to balance your checkbook on your client. It is better to fold a protein on a server, then pass the necessary interface data and you get to see how the protein folding is done in only a few megabytes... instead of terabytes.
"Quite frankly, if we kept on pursuing cloud computing from the 70s, there would be no consumer market for computing, and the few who would 'enjoy' it, would probably be confined to manipulating text data on green screen monitors."
We couldn't continue mainframing from that time because there was not a ubiquitous transport able to pass the kind of interface data needed outside of the corporate infrastructure.
Local PCs gave small businesses the ability to get the computing power in their mainframe sessions locally. And, until Windows, we had exactly that thin client experience on the "PC".
Windows gave us an improved "experience" but at the cost of a race in keeping hardware current with a kind of planned obsolescence schedule.
We are STILL chasing the "experience" on computers that can do everything else BUT formatting content well is STILL being chased - it's why "Glass" is the key improvement in Vista, is it not? It's why the "ribbon" is an "enhancement" and not just another effort to pack more functionality into an application interface...
THE INTERFACE. Not the computing. The interface; a particular amount of content formatted and displayed. Functionality is what the computer actually does when you press that pretty button or sweep over that pretty video.
Mainframes that are thirty years old connected to a beautiful modern interface can make modern thin client stations sing... and THAT is what everyone has missed in this entire equation.
Web platforming allows a modernization of legacy hardware AND legacy software without having to touch the client. When you understand how that happens, you will quickly see precisely what the pundits are seeing. That's why I said: 'Pundits are only reporting what the trends tell them is happening.'
"Pundits are ignoring the trends towards connected desktop applications (away from regular desktop apps) which is proving to be more appealing than regular desktop apps and browser based apps."
Do you know WHY "Pundits are ignoring the trends towards connected desktop applications"? Because there aren't any you can get to across the internet! At least until very recently.
If you're on your corporate intranet, fine. But, tell me please, just how many "connected desktop applications" there are? Microsoft certainly has little and THAT's even on their own network protocols.
THAT is what's ridiculous.
XML allows applications to connect. Microsoft invented SOAP to do it (and SOAP is an RPC system using XML as the conduit) and they can't do that very well. Only on the most stable and private networks.
DO IT ON THE INTERNET and the world might respect MSFT.
The result of Microsoft not being on the internet is their own operating system is being forced into islandhood and the rest of the industry takes the internet as their territory.
It's an architectural thing and there's no getting around those. It's the same thing you get when you build a highway interchange. It's set in concrete and that's the way the cars are going to have to go, so get used to it.
Lamenting the death of a dinosaur is always unbecoming. IBM did it when The Mainframe met the end of its limits in throughput and and reach. The PC applied what the mainframe could do on the desk.
Now, you need a desktop with literally the computing power of many not-so-old mainframes to send email, shop for shoes, and write letters to granny. Who's idea of proper usage is this? Those who want a megalith to prop up their monopoly.
The world wants different.
Since there are broadband leaps being carved out in the telecommunications industry, the server can do much more with what we all really want to do than a costly stranded processor unable to reach out and touch even those of its own kind much less the rest of the world's applications.
The mentality is technological bunkerism and is what happens in the later stages of disruption. It took years for this to play out on IBM.
It's taken only six months to play out on Microsoft and it's only just begun. We haven't even reached the tipping point and we can see the effect accelerating from week to week.
It's due to the nature of the media through which the change is happening. With PC's the adoption period was years. With internet services and applications, the adoption period is extremely fast.
Posted by portuno | April 30, 2008 11:55 PM
P. Douglas :
"The kind of processing that can be done on a client doesn't need the entire library of functions available on the client.
If your hardware could bring in processing capabilities as they became necessary, the infrastructural footprint would be much smaller.
The amount of juggling the kernel would have to do to keep all things computational ready for just that moment when you might want to fold a protein or run an explosives simulation, would be reduced to the things the user really wants and uses."
How then do you expect to work offline? I have nothing against augmenting local processing with cloud processing, but part of the appeal of the client is being able to do substantial work offline during no connection or imperfect / limited network / Internet connection scenarios. Believe me, for most people, limited network / Internet connection scenarios occur all the time. Also, the software + software services architecture minimizes bandwidth demands allowing more applications and more people to benefit from an Internet connection at a particular node. In other words, the above architecture is much more efficient than a dumb terminal architecture, or the one that you are advocating. This means that e.g. in a scenario where you have a movie being downloaded to your Xbox 360, several podcasts automatically being downloaded to your iTunes or Zune client software, your TV schedule being updated in Media Center, your using a browser, etc., and the above being multiplied for several users and several devices at a particular Internet connection, the software + software services architecture is seen to be far better and more practical than a dumb terminal architecture.
Posted by P. Douglas | May 1, 2008 8:04 AM
portuno :
@ P. Douglas,
"How then do you expect to work offline?"
Offline work can be done by a kernel dedicated to the kind of work needed at the time. In other words, instead of a megalith kernel (Vistas is 200MB+) running all functions, you place a kernel (an agent can be ~400KB) optimized for the specific kind of work to tbe done. This kernel can be very small (because it won't be doing ALL processing - only the processing necessary for the tasks selected - it can be only one of multiple kernels interconnected for state determinism) and the resources available online or offline (downloaded when the task is selected).
The big "bugaboo" during the AJAX development efforts in 2005 and 2006 was "how do you work offline"? The agent method places an operational kernel on the client which is a mirror (if necessary) of the processing capability on the remote server. When the system is "online", the kernel cooperates with the server for tasking and processing. When the client is "offline", the local agent does the work, then synchs up the local state with the server when online returns.
No online-offline bugaboo. Just a proper architecture. That's what was needed and AJAX doesn't provide that processing capability. All AJAX was originally intended to do was to reduce that latency between client button push, server response and client update..
"...part of the appeal of the client is being able to do substantial work offline during no connection or imperfect / limited network / Internet connection scenarios."
Correct. And you don't need a megalithic operating system to do that. What you DO need is an architecture that's fitted to take care of both kinds of processing with the most efficient resources AT THE TIME. Not packaged and lugged around waiting for the moment.
"...limited network / Internet connection scenarios occur all the time."
Agreed. So the traditional solution is to load everything that may ever be used on the client? Why don't we use that on-line time to pre-process what can be done and load the client with post processing that is most likely for that task set?
"Also, the software + software services architecture minimizes bandwidth demands allowing more applications and more people to benefit from an Internet connection at a particular node. In other words, the above architecture is much more efficient than a dumb terminal architecture, or the one that you are advocating."
"More efficient" at the cost of much larger demands on local computing resources. Much larger demands on memory (both storage and runtime). Much larger demands on processor speed (the chip has to run the background load of the OS plus any additional support apps running to care for the larger processing load you've accepted).
You will find there will be no "dumb terminals" in the new age. A mix of resources is what the next age requires and a prejudice against a system that was limited by communications constraints 20 years ago doesn't address the problems brought forward by crammed clients.
"This means that e.g. in a scenario where you have a movie being downloaded to your Xbox 360, several podcasts automatically being downloaded to your iTunes or Zune client software, your TV schedule being updated in Media Center, your using a browser, etc., and the above being multiplied for several users and several devices at a particular Internet connection, the software + software services architecture is seen to be far better and more practical than a dumb terminal architecture."
At a much higher cost in hardware, software, maintenance and governance.
Companies are not going to accept your argument when a fit client method is available. The fat client days are spelled out by economics and usefulness.
Because applications can't interoperate (Microsoft's own Office XML format defies interoperation for Microsoft - how is the rest of the world supposed to interoperate?) they are limited in what pre-processing, parallel processing or component processing can be done. The only model most users have any experience with is the fat client model... and the inefficiencies of that model are precisely what all the complaining is about today.
Instead of trying to justify that out-moded model, the industry is accepting a proper mix of capabilities and Microsoft has to face the fact (along with Apple and Linux) that a very large part of their user base can get along just fine with a much more efficient, effective and economical model - being either thin client or fit client.
It's a done deal and the fat client people chose to argue the issues far too late because the megaliths that advocate fat client to maintain their monopolies and legacies no longer have a compelling story.
The remote resources and offloaded burdens tell a much more desirable story.
People listen.
Posted by portuno | May 1, 2008 12:07 PM
P. Douglas :
"Offline work can be done by a kernel dedicated to the kind of work needed at the time. In other words, instead of a megalith kernel (Vistas is 200MB+) running all functions, you place a kernel (an agent can be ~400KB) optimized for the specific kind of work to tbe done. This kernel can be very small (because it won't be doing ALL processing - only the processing necessary for the tasks selected - it can be only one of multiple kernels interconnected for state determinism) and the resources available online or offline (downloaded when the task is selected)."
I don't quite understand what you are saying. Are you saying computers should come with multiple, small, dedicated Operating Systems (OSs)? What do you do then when a user wants to run an application that uses a range of resources spanning the services provided by these multiple OSs? Do you understand the headache this will cause developers? Instead of having to deal with a single coherent set of APIs, they will have deal with multiple overlapping APIs? Also it seems to me that if an application spans multiple OSs, there will be significant latency issues. E.g. if OS A is servicing 3 applications, and one of the applications (App 2) is being serviced by OS B, App 2 will have to wait until OS A is finished servicing requests made by 2 other applications. What you are suggesting would result in unnecessary complexity, and would wind up being overall more resource intensive than a general purpose OS - like the kinds you find in Windows, Mac, and Linux.
"The agent method places an operational kernel on the client which is a mirror (if necessary) of the processing capability on the remote server. When the system is "online", the kernel cooperates with the server for tasking and processing. When the client is "offline", the local agent does the work, then synchs up the local state with the server when online returns."
The software + services architecture is better because: of the reasons I indicated above; a user can reliably do his work on the client (i.e. he is not at the mercy of an Internet connection); data can be synched up just like in your model.
""More efficient" at the cost of much larger demands on local computing resources. Much larger demands on memory (both storage and runtime). Much larger demands on processor speed (the chip has to run the background load of the OS plus any additional support apps running to care for the larger processing load you've accepted)."
Local computing resources are cheap enough and are far more dependable than the bandwidth requirements under your architecture.
"At a much higher cost in hardware, software, maintenance and governance.
Companies are not going to accept your argument when a fit client method is available. The fat client days are spelled out by economics and usefulness."
Thin client advocates have been saying this for decades. The market has replied that the empowerment, and versatility advantages of the PC, outweigh whatever maintenance savings there are in thin client solutions. In other words, it is a user's overall productivity which matters (given the resources he has), and users are overall much more productive and satisfied with PCs, than they are with thin clients.
Posted by P. Douglas | May 1, 2008 2:27 PM
portuno :
P. Douglas:
"I don't quite understand what you are saying. Are you saying computers should come with multiple, small, dedicated Operating Systems (OSs)? "
What would you think Windows 7 will be? More of the same aggregated functionality packaged into a shrinkwrapped package? Would you not make the OS an assembly of interoperable components that could be distributed and deployed when and where needed, freeing the user's machine to use the hardware resources for the user experience rather than as a hot box for holding every dll ever made?
"unnecessary complexity"????
Explain to me how a single OS instance running many threads is less complex than multiple OS functions running their own single threads and passing results and state to downstream (or upstream if you need recursion) processes.
What I've just described is a fundmental structure in higher end operating systems for mainframes. IBM is replacing a system with thousands of servers with only 33 mainframes. What do you think is going on inside those mainframes? And why can't that kind of process work just as well in a single client or a client connected to a server or a client connected to many servers AND many clients fashioned into an ad hoc supercomputer for the period needed?
"Thin client advocates have been saying this for decades."
The most dangerous thing to say is "this road has been this way for years" and driving into the future with your eyes closed.
If your position were correct, we would never be having this conversation. But, we ARE having this conversation because the industry is moving forward and upward and leaving behind those who say "...advocates have been saying this for decades...".
Yada Yada Yada
Posted by portuno | May 1, 2008 3:48 PM