Am Mi, den 14.04.2004 schrieb Guido Casper um 9:08:
Stephan Michels wrote:
The Repository IFs seems be more helper classes than components. And I think we should using the Source objects instead to reflect all aspects like locking, property handling etc.
Care to elaborate why do you think so?
Okay, I try to. For example methods like boolean saveContent(String uri, String content)
shouldn't belong into the interface of a repository. They can easly move
into SourceUtil.
I completely disagree.
Take a look at how linotype works. the .processPipelineTo() method of flowscript is more powerful than any writeablesource because it doesn't force you to encode a ton of parameters in the URI.
the value of writeablesources (destinations?) is that you can use it directly in the sitemap, but since a serializer does not (and will never, as far as I'm concerned) have the ability to specify the destination of its stream (it's not its concern!) you have to resort to a transformer for that that simply is a T-shaped transformer (a multiplexer) that serializes on the other side, and produces eventual error messages in output.
This is a hack.
The pipeline should be producing the stream of bytes, another concern is where those bytes go and how.
<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.
</rant>
In short, we need an API. Whether or not this API will connect to a local repository or to a remote one and what protocol would be used for that communication will be simply another concern that repository users are not supposed to care about.
Note: we *do* need a source to give stuff to generators. JSR 170 has built in SAX-based tree crawling API (that I proposed), so a generator in that regard will not have to do anything, repo: will work just like cocoon: where the generator is transparent.
Another point is that you have to specify your repository base path into cocoon.xconf for the WebDAV. And when you change this, which intention has the "uri"? Doesn't have you all this with the resolver?
If you use flowscript you have to lookup the repository manager IF:
var repositorymanager =
cocoon.getComponent('org.apache.cocoon.components.repository.RepositoryManager');
And not until you login you can lookup the repository
userid = cocoon.request.getParameter("userid");
repository = repositorymanager.getRepository("webdav", new CredentialsToken(new Principal(userid, "guest", null), password));
versioninghelper = repository.getVersioningHelper();
And you have a different behaviour if you use the SourceResolver and the Repository IF together.
Exactly, you shouldn't be using the sourceresolver at all!
var source = resolver.resolveURI("webdav://localhost:8888/webdav"+path);
repository.save(path, "bla");
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]
I don't want to say that's all crap. I only want to express my concerns, so, please don't get me wrong.
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.
JSR 170 was basically crafted exactly for this.
However I use flowscript (which I suspect you don't like :-) for that.
No, I like flowscript, but prefer Java. But nevertheless I currently write a flowscript application, and I found that it is very cumbersome to access the different aspects of an WebDAV repository.
Yes, because you are using WebDAV (a protocol!) as an API and so you think that sources help you with that (but they don't!)
*this* is the problem.
JSR 170 is for WebDAV what the Servlet API is for HTTP.
it's just a matter of using the right tool for the right job.
oh, btw, the first implementation of JSR 170 will probably be over WebDAV so you'd do
your code -(JSR170)-> webdav client ==(WebDAV)==> webdav server -(JSR170)-> repository
where -()-> is inside the JVM and =()=> is across JVMs. Note that the architecture above allows you to do
your code -(JSR170)-> repository
so that you remove overhead if you need it. It also allows non-java clients to connect to your repository (thru the web service exposed thru webdav... webdav is xml-rpc at the end)
So, JSR170 is a repository API, webdav is a repository protocol. You an think of webdav as a transport mechanism for JSR170 or as a web service that exposes JSR170 functionality. And you can think of JSR170 as the API skeleton that hooks you to a webdav web service.
Considering webdav as an API (and therefore abusing source since they are simple forms of protocol adaptation) is the source of all the problems we are having in this domain.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
