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 > Glad you did. Let me do the same, then: In reality it all depends on the client and if he/she has enough balls - has confidence in oneself. Illustration: My daughter needed to submit to a test for her employment agency. The test is on a web page which can only be run on IE with certain requirements like IE6+, flash 8+ and a few other M$(hit) stuff. Well, we have a couple of XPs that don't meet all those requirement. However, since this is somethiing that she really neede, we updated even though I was something that we hated to do as it was only for this one particular need. So, the point is, if it's not a issue of greed or political correctness, have some strength of characcter and do as you see fit. After all, as someone said "make it well and they will come." (Of course, today our greed for power and shekels overrides all that.) And I have personally seen that you can go against the flow and have great success. Doing what you competitor does does not guarantee success, it only promotes mediocrity and furthers greed. So there, I feel better now. :-P :-D -- Hervé Kempf: "Pour sauver la planète, sortez du capitalisme." ------------------------------------------------------------- Phil Jourdan --- pj@xxxxxxxxxxxxx http://www.ptahhotep.com http://www.chiccantine.com/andypantry.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
