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? -- Thanks! -Shawn http://www.spidean.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
