Nathan Rixham wrote: > Shawn McKenzie wrote: >> Nathan Rixham wrote: >>> I just wanted to run this past you guys for thoughts and opinions or >>> even just to get brains ticking, it's all web development related and >>> touched on throughout this thread. >>> >>> At the core of this we have a single problem, we create websites and web >>> based applications, which we want to be delivered to users clients, and >>> have them function and render correctly. >>> >>> This is made impossible because we have multiple client vendors all with >>> varying support for varying features and standards. >>> >>> To solve this we'd need force the users computer to use the client which >>> the application / website was created for use on - similar to >>> conventional software products which run on "x and y platform but not >>> z". >>> >>> The aforementioned forcing is impossible though, we can't force a users >>> computer to switch to firefox for this site and ie for that and so on. >>> >>> It appears to me then that the only way to address this issue would be >>> to literally send the needed client along with the requested content to >>> the users computer and have it open. >>> >>> To achieve this feasibly you'd need to have a sub-client which could run >>> inside any client (or the majority of clients). >>> >>> At this point we have a rough model to work with. >>> >>> currently the model is: >>> >>> user requests content >>> content is sent to users client >>> client determines how it functions and renders. >>> >>> and the new model outlined: >>> >>> user requests content >>> sub-client and content is sent to users client >>> sub-client is launched within users client >>> sub-client determines how it functions and renders. >>> >>> >>> addressing another issue. >>> we often have the need for realtime server client / client server push, >>> without polling - as we know the http protocol does not support this as >>> it's a request response based protocol not a persistent bidirectional >>> (stream based) connection. >>> >>> Thus we'd need the sub-client to support protocols other than http, >>> ideally any form of tcp connection(s) to any port(s) using whichever >>> protocol(s) we require for a specific application. >>> >>> Realistically we'd want our content to be requested, delivered and >>> updated freely, which would mean using the sub-client to handle all of >>> this, connecting up to whatever server based software application(s) we >>> specify. >>> >>> >>> revisiting the model, now we'd need: >>> >>> user requests content >>> sub-client and _content loading instruction_ sent to users client >>> sub-client is launched within users client >>> sub-client connects to server application(s) and requests content. >>> sub-client determines how content functions, updates and renders. >>> >>> this still leaves us with the sub-client determining things for us >>> though, it is a markable improvement though as now we have the user >>> running our application / viewing our content in the client we designed >>> it for. >>> >>> >>> so taking this further >>> what we really need to start this off is a standard sub-client that's >>> lightweight and runs applications, and those applications determine how >>> the content functions, updates and renders. >>> >>> In this scenario we could either select general pre made / third party >>> application to display our content, or create our own application. This >>> application would obviously run inside the sub-client which is inside >>> the users client, and we'd have all the major problems addressed. >>> >>> Speed, in order to keep the speed up with this any client, single >>> sub-client, multiple application scenario it'd be a big bonus if the >>> sub-client was held client side and downloaded / updated as required. >>> >>> >>> updated model: >>> user requests content >>> sub-client required and application location are sent to users client. >>> sub-client is launched within users client >>> sub-client loads required application >>> application connects to server application(s) and requests content. >>> application determines how content functions, updates and renders. >>> >>> >>> other considerations >>> not all requests are made by users, we have bots, spiders and there-in >>> seo to consider here not to mention accessibility. To cut this bit short >>> the obvious answer is two versions of the content (talking text based >>> specifically here), one version that's available if the client doesn't >>> support our sub-client, and another that's loaded inside the >>> application. Alternative content I guess. >>> >>> >>> implementing model using current technologies >>> none of this is any good unless we can do it, and do it with >>> technologies that the majority of users have today - so how does this >>> sound. >>> >>> users client requests content uri via http protocol >>> http response is sent back which includes: >>> - standard format document for bots/accessibility/unsupported clients >>> - sub-client requirement, application location, and instantiation code >>> ... >>> >>> from this point on the application inside the sub-client can forget the >>> http protocol and client limitations and do what we want, the way we >>> want it to. >>> >>> addressing the http response mentioned above, we currently have (x)html >>> supported pretty much everywhere possible, and (x)html supports the >>> <object> which let's objects (sub-clients) run inside a users client. >>> The implementation of <object> lets us specify a data location, type and >>> sizing parameters. Further it also allows us to include (x)html between >>> its tags that will be displayed when our sub-client is not supported. >>> >>> now that's covered all we need is the sub-client and our applications, >>> on the sub-client note, we needed something lightweight, installed >>> client side, and that gave us the freedom to use any connections / >>> protocols we wanted and that could be instructed to render our content >>> however out application specified. >>> >>> finally, if the sub-client was independent, ie not limited to use in >>> clients, could be used on desktops, phones, inside tv hardware etc as >>> well, then our content could be viewed and applications used virtually >>> anywhere. >>> >>> and yeah, we are already at this point we have the ability for all of >>> this, flash / air player being the most prominent example. >>> >>> so all we need is a few server applications and a decent lightweight >>> persistent stateful connection for communication, some standard shared >>> client applications, and of we go! (imho quite sure could extend xmpp a >>> tiny bit to achieve this). >>> >>> lol - i needed to get that out my system >> >> Java anyone? >> > > eh? how do you get java from that? ..... user requests content sub-client required and application location are sent to users client. sub-client is launched within users client sub-client loads required application application connects to server application(s) and requests content. application determines how content functions, updates and renders. ..... finally, if the sub-client was independent, ie not limited to use in clients, could be used on desktops, phones, inside tv hardware etc as well, then our content could be viewed and applications used virtually anywhere. ..... Also, have you ever looked at: http://www.openlaszlo.org? I built one of their small tutorial apps several years ago but it looks much more mature now. -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
