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

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to