Re: [dev] Talk about sane web browsers

On Wed, 09 Sep 2009 04:54:30 -0700, frederic <fdubois76_AT_gmail.com> wrote:

> On Wed, 09 Sep 2009 10:06:20 +0200, Anselm R Garbe <garbeam_AT_gmail.com>
> wrote:
>
>> 2009/9/9 Pinocchio <cchinopio_AT_gmail.com>:
>>>>> I am saying this because even after a lot of marketing muscle and
>>>>> commercial force, it has been hard for Adobe, Sun and Microsoft to
>>>>> push
>>>>> their rendering stacks over HTML + Javascript. Flash is the only thing
>>>>> which gained major adoption... and the picture might change once HTML
>>>>> 5
>>>>> comes out.
>>>>>
>>>>
>>>> The Flash strategy is definitely what I have in mind.
>>>>
>>>
>>> I guess the problem would be convincing the 100s of millions of people
>>> to
>>> install our plugin. Much worse than converting web app developers to our
>>> stack. [I have a feeling I didn't quite get your point here...]
>>
>
> If you can attract the developpers, the users will probably follow. The
> perfect scenario is when a programmer develops a killer application using
> your technology. Users install whatever is required in order to run the
> app. It seems to me that convincing a developper to user your platform is
> the extremely difficult part. This is where the technology has to be a lot
> better in a lot of areas.
>

Hmmm... I guess doing both doesn't harm anybody :)

>> Well, before taking the penetration aspect too far -- it is more
>> important to discuss the actual new web stack first. Key to it is that
>> it provides benefits wrt the existing web stack in many aspects (like
>> flash *yuck* or silverlight -- not too sure about silverlight adoption
>> though), that in itself will drive adoption. (Packaging the new
>> browser as a plugin for legacy browsers would make a lot of sense
>> though to drive adoption.)
>>
>> But what I'm more interested in is this:
>>
>> - knowing the limitations of HTTP and complexity of HTTP/1.1 compliant
>> web servers, shouldn't the new web stack rely on a new protocol
>> instead?
>
> I'm not a specialist, but it seems to me that the only limitation of HTTP
> is its stateless-ness, which forces state management at an upper level at
> the cost of extra complexity. AFAIK caching mechanisms and
> security/encryption are there, but could easily be simpler.
> So it looks like it is a secondary issue.
>

A new protocol would be a good idea. We should probably stick to a subset of HTTP/1.1. Can somebody come up with a transport scenario which cannot be fulfilled by HTTP/1.1?

I think it is a good idea to keep the transport layer state-less. That cleanly separates caching from transport which IMHO is a good thing as applications may want to decide what and how to cache data. However, I do think that putting in support for a content hash based local cache right at the transport layer would be a good idea. By support I really mean that object URIs contain the content hash in them so that the browser can check after resolving a URI whether it really needs to fetch the content.

>> - knowing the limitations of nowadays web applications, how should the
>> content be organized? Should there be a strict separation of
>> data/content and views? How would a scripting interface look like?
>
> The Web has evolved from simple, static, linked together documents servers
> to full-blown applications and two-way communication (FB, twitter etc.).
> All this use-cases coexist nowdays.
> "separation of date and views" is clearly a variation on the "code/data"
> duality. A priori, one should be neutral on this, in order to "perform" in
> an average way in all use-cases. IOW, it should suck averagely in all
> cases.
> As I see it, a simple,static document should be a program that consists
> essentially in a few "print" statements of the text, plus some code for
> link-buttons and font selection etc. Of course, the scripting language
> must be chosen so that it doesn't get too much in the way in this case. A
> full blown app would obviously be 90% of code with a few bits of static
> text.
> However, in this approach the content is mixed with the way it is
> displayed; I think the idea must be refined so that a client may extract
> the content rather than just displaying it.
>

I agree whole heartedly. There is no point of separating code and data at the browser layer. As I have mentioned earlier, I think a cross platform minimal bytecode would be good. I would appreciate feedback on pros and cons of this approach.

>> How would extension points look like?
>
> I'm not sure what you refer to, but one would use the extension mechanism
> of the interpreter of the scripting language.
>

Extensions should be downloaded, cached and run just like the rest of the web app. There is little point in separating local extensions and remote "webapps".

>> What about security to begin with?
>
> This is actually two questions:
> - security of the connexion,
> - safety of the interpreter. As someone else pointed, The whole thing must
> run in a sandbox.
>

Oh... this is the big hairy mess that would need some thought. I think web developers would like cross site code execution + data access. However, at the same time the user should be given control over what a website can or cannot access. I don't think a lot of this can be made backwards compatible with HTML + Javascript. If done well, this could be one of the shining pros our webstack could have compared to HTML + Javascript.

>> - what content should be representable?
>>
>
> The more, the better :) Althought on may select only one or two formats
> for each category of content (image, sound, video, etc.).
>

3D? I think I would just stick with a runtime library which supports 3D, sound and video instead of specing out a declarative language for the content.

I think we need a wiki page for this stuff. Anselm?

-- 
Pinocchio