Gianugo Rabellino wrote:
Stefano Mazzocchi wrote:
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 *
Stefano Mazzocchi wrote:
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
Nicola Ken Barozzi wrote:
Stefano Mazzocchi wrote:
...
I believe that sources have strongly polluted the design of the cocoon
sitemap by making generators obsolete
And generators have been mixing concerns since the beginning, by
specifying both how to get something and how to transform it to
Stefano Mazzocchi wrote:
...
I believe that sources have strongly polluted the design of the cocoon
sitemap by making generators obsolete
And generators have been mixing concerns since the beginning, by
specifying both how to get something and how to transform it to xml.
...
They good sources a
Unico Hommes wrote:
I have been thinking about making the WebDAV samples work with Slide as WebDAV server as well. But throwing out SlideSource is no prerequisite for that.
I have one question re: dropping slide source. If it means using webdav
source instead, how much slower it will be compar
Mats Norén wrote:
Hi,
I've been following the discussions on both the repository API and the
Slide Source and I have a few questions to consider.
The Source IF is an abstraction layer but not a particularly good one in
this context.
I agree that the Slide Source should be dropped but I don´t agr
Stephan Michels wrote:
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
Am Mi, den 14.04.2004 schrieb Guido Casper um 15:21:
> Stephan Michels wrote:
> > The current webdav methods are:
> >
> >
> > ... SUBSCRIBE UNSUBSCRIBE
> > POLL EVENT TRANSACTION ...
>
> Where do these come from? They are not webdav methods.
Okay okay ;-) Not methods of the specs but of Slide,
Stephan Michels wrote:
The current webdav methods are:
... SUBSCRIBE UNSUBSCRIBE
POLL EVENT TRANSACTION ...
Where do these come from? They are not webdav methods.
Guido
--
Guido Casper
-
S&N AG, Competence Center Open Source
Te
Am Mi, den 14.04.2004 schrieb Unico Hommes um 12:09:
> From: Stephan Michels [mailto:[EMAIL PROTECTED]
> > 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.
> -Original Message-
> From: Stephan Michels [mailto:[EMAIL PROTECTED]
> Sent: dinsdag 13 april 2004 19:50
> To: Cocoon Developers
> Subject: [RT] Future of the Slide Source
>
>
> Hi,
>
> I currently think about the Slide/WebDAV access layer, since I
>
Am Mi, den 14.04.2004 schrieb Mats Norén um 10:08:
> Hi,
> I've been following the discussions on both the repository API and the
> Slide Source and I have a few questions to consider.
> The Source IF is an abstraction layer but not a particularly good one in
> this context.
> I agree that the Sl
Stephan Michels wrote:
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
Hi,
I've been following the discussions on both the repository API and the
Slide Source and I have a few questions to consider.
The Source IF is an abstraction layer but not a particularly good one in
this context.
I agree that the Slide Source should be dropped but I don´t agree that
another so
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
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?
I found the partition of work - reading operations via S
Am Di, den 13.04.2004 schrieb Rolf Kulemann um 20:21:
> On Tue, 2004-04-13 at 19:50, Stephan Michels wrote:
> > ...
> > My proposal is to drop the Slide Source, but leave the Slide server as
> > option, and using the Slide block in the same sense as the hsqldb block.
> > So that we can use Slide as
On Tue, 2004-04-13 at 19:50, Stephan Michels wrote:
> ...
> My proposal is to drop the Slide Source, but leave the Slide server as
> option, and using the Slide block in the same sense as the hsqldb block.
> So that we can use Slide as WebDAV server for our WebDAV examples.
>
Does drop mean to re
Stephan Michels wrote:
My proposal is to drop the Slide Source, but leave the Slide server as
option, and using the Slide block in the same sense as the hsqldb block.
So that we can use Slide as WebDAV server for our WebDAV examples.
Sounds good. This could be a good time to review the various Sli
Hi,
I currently think about the Slide/WebDAV access layer, since I
need it for my next project. The access to the Slide repository was my
first approach in the past, and perhaps not the best. The Slide API is
some parts very beautiful, but not intended to be used outside of Slide.
Nevertheless run
20 matches
Mail list logo
