cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Future of the Slide Source
Date Sat, 17 Apr 2004 21:25:23 GMT
Gianugo Rabellino wrote:

> Stefano Mazzocchi wrote:
>> <rant>
>> I believe that sources have strongly polluted the design of the cocoon 
>> sitemap by making generators obsolete
>> I even heard people mentioning things like a xquery: source where you 
>> would encode the xquery in your URI. This has to end.
>> Sources *are* useful, don't get me wrong, but they are easy to abuse 
>> because they represent higher abstractions and like pretty murmaids 
>> seduce you with their portability and reusability.
>> They good sources are the one that you can think about putting in your 
>> browser address textbox: file: http: https: ftp: cocoon: everytime 
>> there is a src="" attribute you need to get the source. it's a 
>> transport mechanism, it indicates *how* you get those bits to you... 
>> it should not be doing anything more than this.
>> The SourceRepository that Gianugo wrote shows pretty evidently how you 
>> can abuse this to a point where it doesn't even make sense anymore and 
>> it's totally useless.
> Oh well, thanks so much... :-)


> I must confess I'm not with you this time. I'm convinced that sources 
> are one of the strongest features of  Cocoon, and I don't quite give a 
> damn about them having obsoleted a few generators (not _all_ of them 
> though: the idea is virtualizing a transport - only generators that need 
> to do more than just bytestream->SAX conversion have been obsoleted. 
> Keep in mind that sources are a transport virtualization *AND* an API 
> (and a good one IMO, where composition shows its power and flexibility).

Well, Sources and Generators do overlap in functionality but not 
completely. What I want is to come up with a design pattern that 
suggests usage of them and avoid abuse.

>> the repository *is* the place where you save, it shouldn't be *you* to 
>> specify where and how to save it.
>> This is what Gianugo did with the SourceRepository and I *do* think 
>> it's terrible design. [no offense, of course, I appreciate the 
>> attempts, especially when they teach you where not to go]
> No offense taken, exp. since you're the one to blame as well. :-) 

Oh, yeah!

> The 
> SourceRepository was more or less a find&replace exercise over your 
> original one which has exactly the same problem, only limited to a local 
> file (you pass it an absolute path anyways, what changes in the 
> SourceRepository is that you're passing a ModifiableSource altogether, 
> which, agreed, is bad). What changes between the two is just
> var home = "/some/path"
> to
> var home = "proto://host/some/path"
> no big deal. :-)

yes, but the problem is that people started to abuse those source using 
the webdav protocol and this blurred the repository contract.

>>>> I found the partition of work - reading operations via Sources 
>>>> (which BTW is their original intention) and modifying operation via 
>>>> Repository - quite useful.
>>> I doesn't think that we should delegate similar aspects into different
>>> code parts.
>> Agreed. We need a repository API and a generator that uses that API to 
>> connect to the repository and streams SAX events out of it.
> I still don't see what is your problem with Sources. I can foresee some 
> security issues since there might be an unexpected direct access instead 
> than going just through the APIs, but this is something that might 
> happen anyways and you protect yourself in other ways.

Oh, there is no security concern, is just a matter of forcing people to 
serialize the contract in one line! That I don't like!

> And, speaking about disagreement between me and you, I really have a 
> problem with your plan:
>> I think that flow changed the picture so much that we now have to 
>> rethink where those sitemap artifacts really still make sense or not.
>> And I mean:
>>  1) actions (I guess everybody agrees on this now)
>>  2) sources (getting there)
>>  3) input/output modules (next target)
> I have the impression that this agenda is going to break the most 
> fundamental design of Cocoon: everything moved to flow breaks horribly 
> the pyramid of contracts, impairs sitemap readability and overall makes 
> maintaining complex applications a nightmare. The beauty of Cocoon is 
> having everything under control in one file (or a set of files with a 
> coherent layout/syntax) geared to non-necessarily overtechies. Everytime 
> you move non-pure-controller functionality to flow, a black hole opens 
> in your sitemap, and you're not under control anymore.
> I noticed this in our last large projects and, well, you have to see to 
> believe. It's incredibly easy to build tangled webs of pipelines calling 
> flows calling pipelines calling flows, where sorting out what happens to 
> a given request is a job for a very skilled developers who have to sort 
> out what happens in a programming language with a procedural approach.
> While I'm with you with actions (pure controller logic), I really have a 
> problem with input/output modules disappearing and with sources being 
> under trial. Whatever moves outside of the sitemap not pure controller 
> logic is dead wrong, IMO.

This sitemap/flow thing is OT here, I'll follow up in Guido's RT.


View raw message