cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Block builder and deployer
Date Thu, 26 May 2005 13:42:59 GMT
David Casal wrote:

> Do you see a point where they'll be
> able to put together semi-complex webapps in LEGO style?

Dude, can you read?

http://cocoon.apache.org/ [very first paragraph]

:-)

[nobody is responding because that's like asking: do you see a future of
open source for this project? WTF man!?!]

> Secondly, if you were to think much further ahead in the future, do you
> see agent-driven applications calling containers which might or might
> not call Cocoon components into a user's 'Webapp Building' tool? Does
> the work Stefano is carrying out at MIT (Simile, PiggyBank) make you
> think of emergent people processing, whereby people might be able to use
> Firefox to build web applications, by having the browser enquire RDF
> repositories for the right components and their dependencies?

Honestly, the whole thing has more the flavor of sci-fi or VC-oriented
BS than any real technology (see below)

> If you read this far, I owe you a beer. Please get creative with your
> answers, comic-book style.
> 
> I'd like to have your wildest dreams for cocoon, even if all I get is
> 'I'd like cocoon to run my house' or 'shut the fuck up you piano playing
> barbarian'.

David,

people are talking about agents, but how is an agent different than a
program? My spam filter saves me hours every single day, it's a very
complex beast and achieves impressive results (better than me, for
sure). Is that an agent? In the "it's working for you sense" it is, if
it's spamassassin, it's also downloading information from the network to
fulfill its task.

Agents and web services are fancy names to describe stuff that we have
been doing since the days the concept of 'client-server' was born. We
are moving into describing the borders of this concepts in a more
precise way, mostly by specifying more on the data being transfered and
the nature of the service interaction, but at the end, it's the same
architectural concept.

Firefox extensions contain RDF that indicates where they come from,
their version and so on. So, in a sort of way, Firefox is a lego-like
semantic agent. But again, that's BS, it's just the way they do things,
not necessarely the only way to achieve the same functionality.

We could write the cocoon blocks metadata in RDF (I would suggest we do
so, but not now), but if the cocoon kernel doesn't support easy
installation, that doesn't buy us anything.

Your dream are not wild at all, btw, they are actually very moderate,
the lego-like approach has been in my vision of cocoon since before
cocoon even started (it was the vision behind avalon). As for automatic
deployment of blocks, again, this was in our vision for avalon already
in 1998, but never managed to get it bootstrapped (and we still struggle
with that here for cocoon blocks).

What I think it's pure BS is the idea that the general population will
use Firefox to build web applications. There is a huge cognitive
difference between seeing your client adapt to your needs, and instruct
it to do so. The second approach is something only a small percentage of
the general population has interest in doing.

I *do* see the ability for a client to be able to download pieces of
code that enable more powerful functionality, but this has to be
transparent, unnoticed, seemless and less intrusive as possible. In such
a sense, the <embed>/<object>/<applet> tags in HTML go in that direction
already, as the iframe-based DHTML embedding used by some (ie. google maps).

And the generation of that HTML might be a result (as in piggy-bank) of
complex, client side operations on a more sofisticated memory model of
the data. In fact, my next task for Piggy-bank is to find a way to allow
'user selectable' views of your data (we call those "lenses"), and there
has been a huge discussion about the feasibility of this approach
declaratively on the general@simile.mit.edu mailing list about the
Fresnel RDF presentation ontology (fresnel, lenses, got it?) (find more
at http://simile.mit.edu/fresnel/)

Yes, the vision is that the user will get more power having to do less,
but this is the vision of pretty much any reasonable technology.

Is not the "what" that counts here (that's the easy part), it's the
"how". And believe me, nobody really has any clue of what is going to
work or what is going to fail miserably (that's why is called 'research')

-- 
Stefano.


Mime
View raw message