cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Casal <>
Subject Re: Block builder and deployer
Date Fri, 27 May 2005 09:35:24 GMT

On 26 May 2005, at 14:42, Stefano Mazzocchi wrote:

>> Do you see a point where they'll be
>> able to put together semi-complex webapps in LEGO style?
> Dude, can you read?
> [very first paragraph]

Patently I cannot ;-)

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

See, actually, my question (which admittedly could be much better put) 

What -kind- of a future do you see, in concrete terms, for Cocoon 
blocks being deployed for a non-programmer (not even XML confs) user 
who has no intention of actually meeting Cocoon at all?

It's not an informed question, its a journalistic question; humble 
apologies for not pre-emptying with 'consider first that I don't know 
what I'm talking 'bout' ;-)

>> 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)

Again, I realise I should have clarified. Imagine a Higher Education 
body saying 'Cocoon is -not- as easy to use for HE developers as it 
advertises it is. Do you see it becoming easier with time, and how?'. 
Those guys want to know more about your thoughts for the future.

At no point does this have anything to do with either VCs, or sci-fi 
for that matter. It's simply a report for a publicly-funded research 
body, on how the people building frameworks like Cocoon see the future.

Let me very very clear here: *do not* confuse these questions as 
anything other than questions related to a JISC report. It has been 
commissioned by Lesley Hawkins (JISC executive, 
and Paul Anderson from Techwatch (, 
who works for JISC. They have no intention of this report being used to 
do anything but inform their channels (FE and HE developers and senior 
decision makers) about available technology.

Of course, when I write about it, it sounds like sci-fi bullshit. It 
does so because my questions are naive. But don't let that put you off 
answering the question (I see below, it didn't).

> 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.

Completely agree. My definition of 'agency' (including its component 
agents) has nothing to do with AI. Too much heuristic emphasis has been 
put on the word agency in the past. I simply mean 'a learning program 
which purports to help a human achieve successful completion of a 
task'. The only reason I see whereby you would call this program and 
'agent', is because like a human helper, it learns overtime. Nothing 
more sci-fi than that.

> 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.

Again, no discussion there.

> 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.

But, a way which is -working- right now. I'm much more interested in 
hearing your thoughts on feasibility than whether the wording is 
correct. To my mind, a piano has been working as a tool for players for 
the last 400 years. The discussion on how to better the tool hasn't 
ended. Its become more granular and therefore less visible to 

> 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.

That's what I'm after. So you see a roadmap whereby first you work on 
easy kernel installation -then- play semantics.

> 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).

Where do you think the struggle to achieve automatic block deployment 
resides? (again, please take this question as journalistic vs. 

> 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.

Ok I getcha. However, the second approach, and its small percentage of 
interested parties is -exactly- the audience of this JISC report. They 
don't necessarily want to know whether they'll be able to build webapps 
through Firefox. They just wonder whether they'll be able to see 
Historians, Musicians, Anthropologists and Librarians build webapps 
without having to understand XML configuration files, or get involved 
in the nature of the framework delivering the components to build those 

My remit for this report is to answer as clearly as I can as to whether 
that is very far in the future or perhaps not as far as they think.

> 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 mailing list about the
> Fresnel RDF presentation ontology (fresnel, lenses, got it?) (find more
> at

Can you see piggy banks being used by applications other than Firefox? 
(I assume because it relies on RDF, Firefox is simple the tool you're 
using for its -present- form, and that anything people write that can 
speak and interact with RDF stores will be able to talk to it).

> 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')

And my commission here is to inform a research agency (JISC) about your 
research and that of everyone involved in Cocoon development. Nothing 

Sorry if that got your back up.

Its a bit like asking a football manager 'so do you think you'll win 
the League this year?'.

In the end, Stefano, it isn't as imbecile a question as you appear to 

Let me put it again in a more straightforward manner : when I introduce 
people to Cocoon in JISC projects, I usually train people who are 
already developers. Their 'project managers' sit back, unaware even of 
the topic, precisely because they've hired programmers to help them 
create whatever webapp/repository/foobarPortal for their research 
discipline. The gap between the two is abismal; Cocoon goes a LONG way 
towards closing that gap already, and everyone hopes it will go 
further. Could you comment on where you'd like make progress to bridge 
the gap between researchers and programmers when building applications 
for the web, and how you think you'll go about it?

This isn't a commercial, VC-led, vampiric question, Stefano. I don't 
have any intention of packaging Cocoon or making nice little shiny toys 
with it. I'll leave people with more time and money and less worries 
than me to do that. Its a question from researchers just like you, but 
from different disciplines (mainly the Humanities), who are hoping the 
tools you guys build will get easier to use with time, and would love 
to now when, how, etc.


Thanks for the reply though, goes a long way towards at least letting 
me know how you feel about it all.



David Plans Casal, Director of Research, Luminas Internet Applications
Tel:  +44 (0)870 741 6658    	Fax:  +44 (0)700 598 1135
Web:	Orixo alliance:

View raw message