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
