Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <4297505B.2030003@apache.org>
Date: Fri, 27 May 2005 12:52:43 -0400
From: Stefano Mazzocchi <stefano@apache.org>
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Block builder and deployer
References: <d6umar$iri$1@sea.gmane.org> <d6vdvq$u1b$1@sea.gmane.org>
 <429353AC.3040802@apache.org> <d6vnn7$6b4$1@sea.gmane.org>
 <42937419.8040900@apache.org> <d70dbc$glb$1@sea.gmane.org>
 <42941299.1070902@apache.org>
 <e11e454da70f039e4532c48d869f62d0@luminas.co.uk>
 <4295D263.7070707@apache.org>
 <4c4edce6a65206343680e8cc3a8ad8d1@luminas.co.uk>
In-Reply-To: <4c4edce6a65206343680e8cc3a8ad8d1@luminas.co.uk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

David Casal wrote:

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

Correct. The other way around would make the goal even harder to
bootstrap. No advancement in an open source software happens if you
don't capture some development momentum that is greater than just one
guy wanting it, especially for such deep and complex architectural issues.

The issues right now are not with semantics, but with the actual
operativity of a block design. (see the excellent various RTs on the matter)

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

in dependency maintenance. see debian, gentoo, bsd ports... the hard
thing is to keep up with the dependency graph, but luckily this is a
very parallizable tasks (in terms of people that can work on it without
stepping on each other toes)

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

I honestly doubt something like that can happen out of cocoon in a short
time... because this community is not interested in it and that
community doesn't have the skills to make it happen technologically (or
even phrase what they want in a way that developers could understand).

>> 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/)
> 
> 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, PB is the firefox plugin, but the engine is called Longwell
(http://simile.mit.edu/longwell/), that's the RDF presentation framework
(you can think of it as a cocoon for RDF) and it's usable (today) already

[note it was first written by our friend Mark Butler]

>> 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 more.
> 
> Sorry if that got your back up.

oh, no problem.

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

yeah, that's how it sounded. :-)

> In the end, Stefano, it isn't as imbecile a question as you appear to
> think.
> 
> 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?

I honestly don't know and it feels to me that the question might be
bogus already. M$ office contains access and it's very easy to use tool
to create a personal database. But how many of the milions of office
users use it? not a lot.

Do we want cocoon to become the ultimate RAD tool? a visual basic for
the web? I don't. It's a lot of pain and no fun at all (content
management systems show you that pain, just allowing them to write
content is such a painful environment to be in)

> This isn't a commercial, VC-led, vampiric question, Stefano. 

Oh, I know, don't worry.

> I don't
> have any intention of packaging Cocoon or making nice little shiny toys
> with it.

And if you did, I wouldn't have a problem with it... because *you* were
going to pay the price for supporting those users, not us ;-)

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

Take the pain of content management and multiply by a thousand. that's
what it feels like to me.

Would we get closer? yes. How? I have no clue. For now, I focus on data
interoperability and that's a hard enough problem to solve, and we just
add a little tiny layer of declerative reasoning and it already has
severe problems.

At the end of the day, non-programmers don't program, they don't like
it, or they can't, their minds don't work like that.

I told you privately to buy Lego mindstorms. Do it. Then play with it.
It's probably the simplest to use programming language ever invented
(and visual!). Do you see a humanity professor using it? I don't.

It's the way their brain works. There is *NOTHING* technology can do to
change that. And even if it could, would I? No. I value diversity of
mental processes more than technological innovation.

-- 
Stefano.