You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ugo Cei <ug...@apache.org> on 2004/03/27 15:33:05 UTC
Linotype
Fellow Cocooners,
after having neglected my weblog for a long time, I'm starting to feel
the urge to blog again, but I want to use a better software than the
homegrown thing I was using before. So I started looking into Linotype
again and decided that it is in need of quite a large refactoring. This
is my plan of action, if nobody objects:
1. remove the ad-hoc authentication system and use container-based
authentication;
2. change the format of entries to something more standard, possibly Atom;
3. finish Gianugo's move to a Source-based repository.
4. add all the missing features.
Comments, anyone?
Ugo
Re: Security in Cocoon blocks
Posted by Stefano Mazzocchi <st...@apache.org>.
Gianugo Rabellino wrote:
> Well, this is not the case actually. I would ship an _open_ Linotype
> (yeah, no username/password) and instruct people to protect it using
> their favourite strategy. This is, after all, what well-behaved Apache
> applications do: auth belongs to <Directory> or .htaccess.
This is what I do for our webapps on simile.mit.edu and I think it makes
perfect sense, but this different from what Ugo was talking about.
--
Stefano.
Security in Cocoon blocks (was: Re: Linotype)
Posted by Gianugo Rabellino <gi...@apache.org>.
Stefano Mazzocchi wrote:
>> Torsten Curdt wrote:
>>
>>> In general I agree but it makes the deployment more
>>> complicated because the authentication differs from
>>> container to container.
>>
>>
>> The container-specific part of the configuration varies, but it's
>> usually not that complicated. And everyone who has ever deployed a
>> J2EE webapp should know it well.
>>
>> Anyway, the current implementation of authentication in Linotype is a
>> toy, so you'd have to rewrite it for a realistic deployment, and
>> whoever wants to deploy Linotype using a different user repository,
>> LDAP for example, or support single sign-on, would have to rewrite it
>> once again.
>
>
>> J2EE has a standardized, declaratively specified, authentication
>> mechanism for web apps, that is good enough for Linotype and most
>> apps. Why reinvent it?
>
>
> Well, there is a big reason: ease of deployment.
*bzzzt*... this is *exactly* what container managed security buys you.
At a price of some configuration (but, hey, it's really easy stuff), you
get integration with your own AAA architecture, no matter what is it
(Basic, Digest, Form, Client cert as mechanism, flat files, SQL, LDAP,
you-name-it as user repository).
Now, whether this is suitable for a personal blogging engine, this is
quite disputable and I can see your point somehow, but for more complex
applications I see no other way. Why reinvent wheels all over? During
the past years I've see all kinds of self-baked AAA solutions and _very
few_ of them were HTTP compliant (and IIRC, Linotype actually isn't)
since they were just layered on top (as in HTTP 200 all over instead
than 401's with authentication performed per request).
> Linotype will be block and people will want us to deploy a block and
> forget about it.
Uh-oh, this brings a big issue on the table. You will have a hell of a
hard time to convince me that Cocoon (blocks) shouldn't support
container managed authentication. If you're serious about HTTP security,
you cannot just forget about CMA, since you will have to forget about
pluggable authentication mechanism, pluggable authentication layers, SSL
aware logins, single sign-on solutions and all the like. Or reinvent
them (and maintain them!) yourself. SoC, mate: authentication is part of
the HTTP protocol, let's use it the way it was designed. :-)
> We don't spend 18 months of design to come up with something that is
> totally hotdeployable and rewritable and then you throw it down the
> drain because you have to restart the container because you have to add
> your own little thing in the webapp deployment descriptor.
I'm all for finding a better solution, but I really can't see any ATM,
apart from (again) just reinventing stuff.
>
> Why reinvent what J2EE sucked at?
>
This is not J2EE, this is plain HTTP. You can re-invent it, if you wish,
but you'll have to reinvent a huge pile of stuff.
well, I thought that was the reason to
> for doing cocoon in the first place.
>
> I'm all for a better authentication strategy but if this doesn't work
> with our way of doing stuff, well, it's not going to help anybody.
>
>>> We would need to maintain examples for the different
>>> containers... The login page might also need to
>>> be different per container.
>>
>>
>> We can easily provide a configuration for Jetty, since that's what we
>> distribute for running the examples (I already did and will commit it
>> soon). Adding another one for Tomcat wouldn't be a problem at all.
>
>
> See, that's exactly what I mean.
Well, this is not the case actually. I would ship an _open_ Linotype
(yeah, no username/password) and instruct people to protect it using
their favourite strategy. This is, after all, what well-behaved Apache
applications do: auth belongs to <Directory> or .htaccess.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Blogging at: http://www.rabellino.it/blog/)
Re: Linotype
Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> Il giorno 31/mar/04, alle 19:23, Stefano Mazzocchi ha scritto:
>
>> Ugo Cei wrote:
>>
>>> Atom and RSS are more or less isomorphic to the current markup, so
>>> it's not really important to switch right now. I'll try to fix what's
>>> broken with what we have and we'll decide later.
>>
>>
>> Wait, I have already done that. I will commit tomorrow night (european
>> time), is that ok?
>>
> OK, I'll wait for your commit.
cool
--
Stefano.
Re: Linotype
Posted by Ugo Cei <u....@cbim.it>.
Il giorno 31/mar/04, alle 19:23, Stefano Mazzocchi ha scritto:
> Ugo Cei wrote:
>
>> Atom and RSS are more or less isomorphic to the current markup, so
>> it's not really important to switch right now. I'll try to fix what's
>> broken with what we have and we'll decide later.
>
> Wait, I have already done that. I will commit tomorrow night (european
> time), is that ok?
>
OK, I'll wait for your commit.
Ugo
Re: Linotype
Posted by Stefano Mazzocchi <st...@apache.org>.
Ugo Cei wrote:
> Atom and RSS are more or less isomorphic to the current markup, so it's
> not really important to switch right now. I'll try to fix what's broken
> with what we have and we'll decide later.
Wait, I have already done that. I will commit tomorrow night (european
time), is that ok?
--
Stefano.
Re: Linotype
Posted by Ugo Cei <u....@cbim.it>.
Stefano Mazzocchi wrote:
> I'm all for a better authentication strategy but if this doesn't work
> with our way of doing stuff, well, it's not going to help anybody.
I'm not going to repeat here all the arguments that Gianugo has put
forward in his reply, but just say that I agree 100% with what he said.
It's certainly true that J2EE sucks in many respects, but since we're
still using the Servlet spec that's part of J2EE, we should adhere to it
for what it's worth. I hope that one day, Cocoon won't be a Servlet
anymore and serve HTTP requests by itself, providing authentication and
authorization to blocks in a transparent, hot-deployable way. On that
day, blocks won't try do do AAA by themselves, each one in a different
way, but will delegate it to the Cocoon Kernel, just like today they
should delegate it to the Servlet container.
I also agree with him that we could ship Linotype without
authentication. We could also ship with a commented-out
<security-constraint> section in web.xml (plus a file-based realm for
Jetty) and put a prominent notice in the homepage that if people want to
enable authentication, they just have to uncomment it, and possibly
setup a realm in their container of choice, if not using the provided Jetty.
> There is no need to use a standard markup for something that nobody is
> ever going to see. I'm happy to move to a more cocoon oriented namespace
> and move away from my own, but I don't see the need for use a markup
> that was invented for feeds and not as a storage markup.
Atom and RSS are more or less isomorphic to the current markup, so it's
not really important to switch right now. I'll try to fix what's broken
with what we have and we'll decide later.
Ugo
Re: Linotype
Posted by Stefano Mazzocchi <st...@apache.org>.
On Mar 27, 2004, at 19:47, Ugo Cei wrote:
> Torsten Curdt wrote:
>> In general I agree but it makes the deployment more
>> complicated because the authentication differs from
>> container to container.
>
> The container-specific part of the configuration varies, but it's
> usually not that complicated. And everyone who has ever deployed a
> J2EE webapp should know it well.
>
> Anyway, the current implementation of authentication in Linotype is a
> toy, so you'd have to rewrite it for a realistic deployment, and
> whoever wants to deploy Linotype using a different user repository,
> LDAP for example, or support single sign-on, would have to rewrite it
> once again.
> J2EE has a standardized, declaratively specified, authentication
> mechanism for web apps, that is good enough for Linotype and most
> apps. Why reinvent it?
Well, there is a big reason: ease of deployment.
Linotype will be block and people will want us to deploy a block and
forget about it.
We don't spend 18 months of design to come up with something that is
totally hotdeployable and rewritable and then you throw it down the
drain because you have to restart the container because you have to add
your own little thing in the webapp deployment descriptor.
Why reinvent what J2EE sucked at? well, I thought that was the reason
to for doing cocoon in the first place.
I'm all for a better authentication strategy but if this doesn't work
with our way of doing stuff, well, it's not going to help anybody.
>> We would need to maintain examples for the different
>> containers... The login page might also need to
>> be different per container.
>
> We can easily provide a configuration for Jetty, since that's what we
> distribute for running the examples (I already did and will commit it
> soon). Adding another one for Tomcat wouldn't be a problem at all.
See, that's exactly what I mean.
> I am talking specifically about a file-based user realm, no JDBC so
> there would be no dependencies.
>
> WRT the login page, I routinely use the same page for Jetty and
> Tomcat, so I suppose it's standard. But you can always use BASIC
> authentication and do without a login page.
>
>> But wouldn't this limit us to the particular "features"/stuctur of
>> that
>> markup. (Well, except using a different namespace) And what is the
>> benefit? We could save a transformation.
>
> Atom (and I think also RSS 2.0) can be extended with elements from
> other namespaces, indeed. And we could also ask for changes to the
> Atom spec, since it's still in draft stage. Anyway, what do you
> suggest that we use as an alternative?
There is no need to use a standard markup for something that nobody is
ever going to see. I'm happy to move to a more cocoon oriented
namespace and move away from my own, but I don't see the need for use a
markup that was invented for feeds and not as a storage markup.
--
Stefano.
Re: Linotype
Posted by Ugo Cei <u....@cbim.it>.
Gianugo Rabellino wrote:
> Ugo Cei wrote:
>> Atom (and I think also RSS 2.0) can be extended with elements from
>> other namespaces, indeed. And we could also ask for changes to the
>> Atom spec, since it's still in draft stage. Anyway, what do you
>> suggest that we use as an alternative?
> I'm a bit skeptical that a syndication format is able to comfortably
> include every possible repository issue that a blog has (think
> comments). But I'm open to be proven wrong.
Sincerely, I don't know if I'll be able to prove you wrong. I'll try to
come up with something working in the next days, then we'll se if it's
enough or not.
Ugo
Re: Linotype
Posted by Gianugo Rabellino <gi...@apache.org>.
Ugo Cei wrote:
> Torsten Curdt wrote:
>
>> In general I agree but it makes the deployment more
>> complicated because the authentication differs from
>> container to container.
>
>
> The container-specific part of the configuration varies, but it's
> usually not that complicated. And everyone who has ever deployed a J2EE
> webapp should know it well.
>
> Anyway, the current implementation of authentication in Linotype is a
> toy, so you'd have to rewrite it for a realistic deployment, and whoever
> wants to deploy Linotype using a different user repository, LDAP for
> example, or support single sign-on, would have to rewrite it once again.
>
> J2EE has a standardized, declaratively specified, authentication
> mechanism for web apps, that is good enough for Linotype and most apps.
> Why reinvent it?
Totally agree, in general Container Managed Security is the most
portable ever. However, it's also true that for demo purposes and quick,
personal, installation it might be overkill to configure realms and
web.xml for that (I'm doing it however, for the record).
>> But wouldn't this limit us to the particular "features"/stuctur of that
>> markup. (Well, except using a different namespace) And what is the
>> benefit? We could save a transformation.
>
>
> Atom (and I think also RSS 2.0) can be extended with elements from other
> namespaces, indeed. And we could also ask for changes to the Atom spec,
> since it's still in draft stage. Anyway, what do you suggest that we use
> as an alternative?
I'm a bit skeptical that a syndication format is able to comfortably
include every possible repository issue that a blog has (think
comments). But I'm open to be proven wrong.
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Blogging at: http://www.rabellino.it/blog/)
Re: Linotype
Posted by Ugo Cei <ug...@apache.org>.
Torsten Curdt wrote:
> In general I agree but it makes the deployment more
> complicated because the authentication differs from
> container to container.
The container-specific part of the configuration varies, but it's
usually not that complicated. And everyone who has ever deployed a J2EE
webapp should know it well.
Anyway, the current implementation of authentication in Linotype is a
toy, so you'd have to rewrite it for a realistic deployment, and whoever
wants to deploy Linotype using a different user repository, LDAP for
example, or support single sign-on, would have to rewrite it once again.
J2EE has a standardized, declaratively specified, authentication
mechanism for web apps, that is good enough for Linotype and most apps.
Why reinvent it?
> We would need to maintain examples for the different
> containers... The login page might also need to
> be different per container.
We can easily provide a configuration for Jetty, since that's what we
distribute for running the examples (I already did and will commit it
soon). Adding another one for Tomcat wouldn't be a problem at all.
I am talking specifically about a file-based user realm, no JDBC so
there would be no dependencies.
WRT the login page, I routinely use the same page for Jetty and Tomcat,
so I suppose it's standard. But you can always use BASIC authentication
and do without a login page.
> But wouldn't this limit us to the particular "features"/stuctur of that
> markup. (Well, except using a different namespace) And what is the
> benefit? We could save a transformation.
Atom (and I think also RSS 2.0) can be extended with elements from other
namespaces, indeed. And we could also ask for changes to the Atom spec,
since it's still in draft stage. Anyway, what do you suggest that we use
as an alternative?
Ugo
Re: Linotype
Posted by Torsten Curdt <tc...@vafer.org>.
> Yes, I already did it. Now I just need to remove all the code dealing
> with authentication from the flowscript. Do you see a problem with that?
> I only see benefits:
>
> - less code to maintain
> - possibility of using different user repositories (file, JDBC, LDAP,
> ...) via standard inderfaces
> - Single Sign-On
In general I agree but it makes the deployment more
complicated because the authentication differs from
container to container.
We would need to maintain examples for the different
containers... The login page might also need to
be different per container.
Hm... :-/ don't know
>>> 2. change the format of entries to something more standard, possibly
>>> Atom;
>>
>>
>>
>> Isn't that a question of the right stylesheet?
>
>
> You have to store items in some form or another, even if you can use
> XSL-T to transform them to something else later. I'm proposing to use
> something standard, again (Atom or RSS) instead of a made-up markup.
But wouldn't this limit us to the particular "features"/stuctur of that
markup. (Well, except using a different namespace) And what is the
benefit? We could save a transformation.
Hm... :-/ don't know
Sorry for coming across so negative ;)
cheers
--
Torsten
Re: Linotype
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Ugo Cei wrote:
> You have to store items in some form or another, even if you can use
> XSL-T to transform them to something else later. I'm proposing to use
> something standard, again (Atom or RSS) instead of a made-up markup.
the lenya weblog publication is based on atom and has partial atom api
support too. maybe the two can be merged?
--
Gregor J. Rothfuss
Wyona Inc. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
Re: Linotype
Posted by Ugo Cei <u....@cbim.it>.
Torsten Curdt wrote:
> Ugo Cei wrote:
>> 1. remove the ad-hoc authentication system and use container-based
>> authentication;
>
>
> Hm... you'd have to configure the container
> for authentication :-/ don't know
Yes, I already did it. Now I just need to remove all the code dealing
with authentication from the flowscript. Do you see a problem with that?
I only see benefits:
- less code to maintain
- possibility of using different user repositories (file, JDBC, LDAP,
...) via standard inderfaces
- Single Sign-On
>> 2. change the format of entries to something more standard, possibly
>> Atom;
>
>
> Isn't that a question of the right stylesheet?
You have to store items in some form or another, even if you can use
XSL-T to transform them to something else later. I'm proposing to use
something standard, again (Atom or RSS) instead of a made-up markup.
> Would also be good to eat our own dog food.
That is one of my motivations also.
Ugo
Re: Linotype
Posted by Torsten Curdt <tc...@vafer.org>.
Ugo Cei wrote:
> Fellow Cocooners,
>
> after having neglected my weblog for a long time, I'm starting to feel
> the urge to blog again, but I want to use a better software than the
> homegrown thing I was using before. So I started looking into Linotype
> again and decided that it is in need of quite a large refactoring. This
> is my plan of action, if nobody objects:
>
> 1. remove the ad-hoc authentication system and use container-based
> authentication;
Hm... you'd have to configure the container
for authentication :-/ don't know
> 2. change the format of entries to something more standard, possibly Atom;
Isn't that a question of the right stylesheet?
> 3. finish Gianugo's move to a Source-based repository.
>
> 4. add all the missing features.
I am also feeling the urge to move away from movabletype.
I can't stand this perl stuff anymore.
Would also be good to eat our own dog food.
cheers
--
Torsten
Re: Repository
Posted by Guido Casper <gc...@s-und-n.de>.
Rolf Kulemann wrote:
> On Thu, 2004-04-01 at 22:05, Rolf Kulemann wrote:
>
>>What interests me is:
>>
>> What do u plan for versioning regarding the repository interface?
>
>
> I think I found the answer myself. There is this
> RepoitoryVersioningHelper which provides the functionality I searched.
>
> Is it right that we need one VersioningHelper for each repository impl.
> i.e. one for Slide?
>
> U plan to have things like(?):
>
> SlideRepository implements Repository
> SlideRepositoryVersiongHelper implements RepositoryVersioningHelper
Yes, and
MySimpleNonversioningFilesystemRepo.getVersioningHelper();
returns null.
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:gcasper@s-und-n.de
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
Re: Repository
Posted by Rolf Kulemann <ro...@apache.org>.
On Thu, 2004-04-01 at 22:05, Rolf Kulemann wrote:
> What interests me is:
>
> What do u plan for versioning regarding the repository interface?
I think I found the answer myself. There is this
RepoitoryVersioningHelper which provides the functionality I searched.
Is it right that we need one VersioningHelper for each repository impl.
i.e. one for Slide?
U plan to have things like(?):
SlideRepository implements Repository
SlideRepositoryVersiongHelper implements RepositoryVersioningHelper
??
--
Regards,
Rolf Kulemann
Re: Repository
Posted by Rolf Kulemann <ro...@apache.org>.
On Fri, 2004-04-02 at 17:20, Guido Casper wrote:
> Rolf Kulemann wrote:
> > [...]
> > A very important question for me:
> >
> > When can there be some alpha code seeds available in cvs?
> >
> > I saw there is sth. changing already in the repository block.
> > I'm especially interested in versioning of the rep. sources.
>
> I just committed an impl for WebDAV. It needs completion and more
> testing (I'll come up with samples later).
Guido, I very much like what you checked in the otherday.
I directly started to do a "personal" sample with your WebDAV repository
impl.
Thanks very much.
--
Regards,
Rolf Kulemann
Re: Repository
Posted by Guido Casper <gc...@s-und-n.de>.
Rolf Kulemann wrote:
> On Fri, 2004-04-02 at 11:40, Guido Casper wrote:
>
>>>>-link management
>>>
>>>
>>>What do u mean? I thin forrests LinkRewriter is doing a fine job. Please
>>>explain your idea in more detail.
>>
>>I'm thinking of managing linking information within metadata/properties
>>in a bidirectional way so that broken links may be prevented/detected
>>early on in the authoring process.
>
>
> Mmmh. Ok, I understand your requirement. I thought, if we use "hrefs"
> like "site:..." and the LinkRewriter we do not need to care about broken
> links etc, since we refer to a symbolic href target in docs only. We
> only need to maintain the link db for the LinkRewriter which itself (the
> db) is a doc in the repository.
>
> Does that make sense?
Yes I think LinkRewriter is nice for many use cases. But it doesn't
answer what happens if you delete a document being linked by another
document. And I'm unsure wether maintaining a central link db is a good
way to do this kind of link management. I see LinkRewriter somehow
orthogonal to what I have in mind.
But currently it's not much more than an idea (there is no code) and I'm
interested to hear other opinions.
>
>
>
>>>>-a RepositorySource(2)
>>>
>>>
>>>I thought of that, too. Please explain your idea in more detail :)
>>>
>>>So u want users to act on a RepositrySource instance instead of the
>>>single interfaces like TraversableSource and VersionableSource for
>>>example?
>>
>>No, I mean a Source implementation implementing all the needed
>>subinterfaces while operating only on the Repository interface
>>(currently lacking getChildren() etc. for the traversable stuff). So
>>that not every repository needs to implement its own Source.
>
>
> Ah, ok.
>
>
>>For a particular repository, implementing the Repository interface may
>>in summary be the same amount of work (although you may be less
>>distracted by the special semantics of Sources), but you get more
>>functionality (and better testability) and the Source implementation
>>comes for free.
>
>
> Ok.
>
>
> A very important question for me:
>
> When can there be some alpha code seeds available in cvs?
>
> I saw there is sth. changing already in the repository block.
> I'm especially interested in versioning of the rep. sources.
I just committed an impl for WebDAV. It needs completion and more
testing (I'll come up with samples later).
However I'm currently not working on a RepositorySource.
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:gcasper@s-und-n.de
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
Re: Repository
Posted by Rolf Kulemann <ro...@apache.org>.
On Fri, 2004-04-02 at 11:40, Guido Casper wrote:
> >>-link management
> >
> >
> > What do u mean? I thin forrests LinkRewriter is doing a fine job. Please
> > explain your idea in more detail.
>
> I'm thinking of managing linking information within metadata/properties
> in a bidirectional way so that broken links may be prevented/detected
> early on in the authoring process.
Mmmh. Ok, I understand your requirement. I thought, if we use "hrefs"
like "site:..." and the LinkRewriter we do not need to care about broken
links etc, since we refer to a symbolic href target in docs only. We
only need to maintain the link db for the LinkRewriter which itself (the
db) is a doc in the repository.
Does that make sense?
> >>-a RepositorySource(2)
> >
> >
> > I thought of that, too. Please explain your idea in more detail :)
> >
> > So u want users to act on a RepositrySource instance instead of the
> > single interfaces like TraversableSource and VersionableSource for
> > example?
>
> No, I mean a Source implementation implementing all the needed
> subinterfaces while operating only on the Repository interface
> (currently lacking getChildren() etc. for the traversable stuff). So
> that not every repository needs to implement its own Source.
Ah, ok.
>
> For a particular repository, implementing the Repository interface may
> in summary be the same amount of work (although you may be less
> distracted by the special semantics of Sources), but you get more
> functionality (and better testability) and the Source implementation
> comes for free.
Ok.
A very important question for me:
When can there be some alpha code seeds available in cvs?
I saw there is sth. changing already in the repository block.
I'm especially interested in versioning of the rep. sources.
--
Regards,
Rolf Kulemann
Re: Repository
Posted by Guido Casper <gc...@s-und-n.de>.
Rolf Kulemann wrote:
> On Fri, 2004-04-02 at 08:34, Guido Casper wrote:
>>On top of this other higher level components might be build. Among the
>>things I have in mind are:
>>-a document store accommodating a certain array of use cases and being
>>simple to use from the flow layer (in fact there might be different
>>kinds of document stores being shielded from the particular repository
>>implementation)
>>-a workflow component (although that shouldn't be bound to the repository)
>
>
> Good point. For workflow info is expressed through metadata/properties I
> bound to "document" stored in a repository. At the mom Lenya uses a set
> of xml to express workflow states etc. which is also somehow bound to a
> document.
>
> Of course workflow is needed, but has nothing to do with the repository.
> The repository interface should simply enable annotating "docs" with
> appropiate wf metadata/properties.
>
> Makes sense?
Yes, just have some kind of "WorkflowObject" that serves as a decoupling
adapter between workflow and repository so that workflow can be used
with other components as well.
>
>
>>-link management
>
>
> What do u mean? I thin forrests LinkRewriter is doing a fine job. Please
> explain your idea in more detail.
I'm thinking of managing linking information within metadata/properties
in a bidirectional way so that broken links may be prevented/detected
early on in the authoring process.
>
>
>
>>-a RepositorySource(2)
>
>
> I thought of that, too. Please explain your idea in more detail :)
>
> So u want users to act on a RepositrySource instance instead of the
> single interfaces like TraversableSource and VersionableSource for
> example?
No, I mean a Source implementation implementing all the needed
subinterfaces while operating only on the Repository interface
(currently lacking getChildren() etc. for the traversable stuff). So
that not every repository needs to implement its own Source.
For a particular repository, implementing the Repository interface may
in summary be the same amount of work (although you may be less
distracted by the special semantics of Sources), but you get more
functionality (and better testability) and the Source implementation
comes for free.
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:gcasper@s-und-n.de
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
Re: Repository (was Re: Linotype)
Posted by Rolf Kulemann <ro...@apache.org>.
On Fri, 2004-04-02 at 08:34, Guido Casper wrote:
> Rolf Kulemann wrote:
> [...]
> > Important is imho, that all "repositories" are isolated by a common
> > repository interface.
>
> Yes I intend the Repository interface to be a (low level) facade into
> different kind of implementations like slide, jcr, webdav or an extended
> version of the current SourceRepositoryImpl (so you can run samples with
> nothing but the filesystem and HSQL).
Exactly.
>
> It feels easier to manage and to use than to squeeze everything through
> the Source interface - at least for modifying operations. For read
> access Sources of course have it's use and the Source/Repository combo
> seems to be a powerful concept.
>
> On top of this other higher level components might be build. Among the
> things I have in mind are:
> -a document store accommodating a certain array of use cases and being
> simple to use from the flow layer (in fact there might be different
> kinds of document stores being shielded from the particular repository
> implementation)
> -a workflow component (although that shouldn't be bound to the repository)
Good point. For workflow info is expressed through metadata/properties I
bound to "document" stored in a repository. At the mom Lenya uses a set
of xml to express workflow states etc. which is also somehow bound to a
document.
Of course workflow is needed, but has nothing to do with the repository.
The repository interface should simply enable annotating "docs" with
appropiate wf metadata/properties.
Makes sense?
> -link management
What do u mean? I thin forrests LinkRewriter is doing a fine job. Please
explain your idea in more detail.
> -a RepositorySource(2)
I thought of that, too. Please explain your idea in more detail :)
So u want users to act on a RepositrySource instance instead of the
single interfaces like TraversableSource and VersionableSource for
example? Would make sense. That would mean every "source provider"
should implement a RepositorySource/Factory?
--
Regards,
Rolf Kulemann
Repository (was Re: Linotype)
Posted by Guido Casper <gc...@s-und-n.de>.
Rolf Kulemann wrote:
> On Sat, 2004-03-27 at 16:31, Guido Casper wrote:
>
>>Concerning the repository ... I just committed another repository
>>interface :-) that tries to be a best effort in consolidating all the
>>different approaches and accommodating all concerns in a flexible way
>>(by having opional helpers for property management, versoning and
>>transaction management).
>>
>>Like suggested in this thread
>>http://marc.theaimsgroup.com/?t=107022316500003&r=1&w=2
>>
>>the approach does not intend to build upon the source interface but to
>>provide an interface for different repository implementations (on top of
>>which a RepositorySource might be implemented).
>>
>>I'll try to come up with a first cut of an implementation for a WebDAV
>>repository by the end of next weekend.
>
>
> Cool.
>
> We in the Lenya land also plan to "use a kind of repository". We tried
> to gather all our repository interface requirements in
> http://wiki.cocoondev.org/Wiki.jsp?page=LenyaRepositoryRequirements .
>
> The last days I played around with the slide block. For example I used
> the SlideSource and the repository block to save and read from slide.
>
> The main lack of the repository interface or slide source was:
>
> - How to access versioning functionality
>
> I see two obvious approaches:
>
> 1.) Directly use the interface VerisonableSource which is implemented by
> SlideSource or use the Repository interface to create new versions etc.
> The problem is
> * The repository interface supports no methods for versioning
> * SlideSource does implement the VersionableSource but the appropiate
> method bodies are quite empty.
>
> What interests me is:
>
> What do u plan for versioning regarding the repository interface?
There is a RepositoryVersioningHelper interface which may serve as a
starting point for most versioning needs.
>
>
> FYI:
>
> In Lenya land we tend to use JCR in the future and think about using
> Slide somehow now. I think the best would be to isolate slide/jcr by a
> repositroy layer in cocoon. Of course WebDAV plays a role , too. I can
> imagine WebDAV under JCR or a raw WEBdav based repository
> implementation.
>
> Important is imho, that all "repositories" are isolated by a common
> repository interface.
Yes I intend the Repository interface to be a (low level) facade into
different kind of implementations like slide, jcr, webdav or an extended
version of the current SourceRepositoryImpl (so you can run samples with
nothing but the filesystem and HSQL).
It feels easier to manage and to use than to squeeze everything through
the Source interface - at least for modifying operations. For read
access Sources of course have it's use and the Source/Repository combo
seems to be a powerful concept.
On top of this other higher level components might be build. Among the
things I have in mind are:
-a document store accommodating a certain array of use cases and being
simple to use from the flow layer (in fact there might be different
kinds of document stores being shielded from the particular repository
implementation)
-a workflow component (although that shouldn't be bound to the repository)
-link management
-a RepositorySource(2)
I would be interested what Lenya land (and others) thinks of such an
approach.
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:gcasper@s-und-n.de
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------
Re: Linotype
Posted by Rolf Kulemann <ro...@apache.org>.
On Sat, 2004-03-27 at 16:31, Guido Casper wrote:
> Concerning the repository ... I just committed another repository
> interface :-) that tries to be a best effort in consolidating all the
> different approaches and accommodating all concerns in a flexible way
> (by having opional helpers for property management, versoning and
> transaction management).
>
> Like suggested in this thread
> http://marc.theaimsgroup.com/?t=107022316500003&r=1&w=2
>
> the approach does not intend to build upon the source interface but to
> provide an interface for different repository implementations (on top of
> which a RepositorySource might be implemented).
>
> I'll try to come up with a first cut of an implementation for a WebDAV
> repository by the end of next weekend.
Cool.
We in the Lenya land also plan to "use a kind of repository". We tried
to gather all our repository interface requirements in
http://wiki.cocoondev.org/Wiki.jsp?page=LenyaRepositoryRequirements .
The last days I played around with the slide block. For example I used
the SlideSource and the repository block to save and read from slide.
The main lack of the repository interface or slide source was:
- How to access versioning functionality
I see two obvious approaches:
1.) Directly use the interface VerisonableSource which is implemented by
SlideSource or use the Repository interface to create new versions etc.
The problem is
* The repository interface supports no methods for versioning
* SlideSource does implement the VersionableSource but the appropiate
method bodies are quite empty.
What interests me is:
What do u plan for versioning regarding the repository interface?
FYI:
In Lenya land we tend to use JCR in the future and think about using
Slide somehow now. I think the best would be to isolate slide/jcr by a
repositroy layer in cocoon. Of course WebDAV plays a role , too. I can
imagine WebDAV under JCR or a raw WEBdav based repository
implementation.
Important is imho, that all "repositories" are isolated by a common
repository interface.
> > Comments, anyone?
--
Regards,
Rolf Kulemann
Re: Linotype
Posted by Ugo Cei <ug...@apache.org>.
Guido Casper wrote:
> Concerning the repository ... I just committed another repository
> interface :-) that tries to be a best effort in consolidating all the
> different approaches and accommodating all concerns in a flexible way
> (by having opional helpers for property management, versoning and
> transaction management).
Admittedly, I'm still trying to wrap my head around all this repository
and source stuff. Mainly I do Cocoon applications on SQL databases, so
I'm not very familiar with other sources.
> I'll try to come up with a first cut of an implementation for a WebDAV
> repository by the end of next weekend.
I'll wait for your commit. In the meantime, I'll try to learn.
Ugo
Re: Linotype
Posted by Guido Casper <gc...@s-und-n.de>.
Ugo Cei wrote:
> Fellow Cocooners,
>
> after having neglected my weblog for a long time, I'm starting to feel
> the urge to blog again, but I want to use a better software than the
> homegrown thing I was using before. So I started looking into Linotype
> again and decided that it is in need of quite a large refactoring. This
> is my plan of action, if nobody objects:
>
> 1. remove the ad-hoc authentication system and use container-based
> authentication;
>
> 2. change the format of entries to something more standard, possibly Atom;
>
> 3. finish Gianugo's move to a Source-based repository.
Concerning the repository ... I just committed another repository
interface :-) that tries to be a best effort in consolidating all the
different approaches and accommodating all concerns in a flexible way
(by having opional helpers for property management, versoning and
transaction management).
Like suggested in this thread
http://marc.theaimsgroup.com/?t=107022316500003&r=1&w=2
the approach does not intend to build upon the source interface but to
provide an interface for different repository implementations (on top of
which a RepositorySource might be implemented).
I'll try to come up with a first cut of an implementation for a WebDAV
repository by the end of next weekend.
Guido
>
> 4. add all the missing features.
>
>
> Comments, anyone?
>
> Ugo
>
>