Re: DISCUSSION: Slide 2.0 release
On 18 Nov 2003, at 03:36, Daniel Florey wrote: [snip...] My favorit issues are: - Getting the stores to work as expected (at least file/db-stores) this is critical, yes. - Implement internal locking (should not be transactional) can you tell us more about this? I think we need two different types of locks in slide: First there are webdav-locks that should be acquired/released transactional. This means that it should be possible to acquire a number of locks in one transactional and rollback the whole transaction when a single lock fails. Bedides this there is a need for internal global locks that handle concurrents modifications. Think of two copy operations in different transactions where every user wants to to copy to the same target. At the moment this is delegated to underlying stores in a not very beatyful manner (recursive read)... Olli will start a thread on this to discuss this in more detail. ok, I agree that's better to separate issues in different threads. - Improve and fix caching. It's not fully transactional in some places and can be improved (especially lock/permission-cache) same here, do you have any idea on how to do this? [curious] First and most easy would be to disable caching :-) well :-) If caching is enabled, it must be ensured that the cache is always consistent. yep At the moment there a some places, where for example invalid data remains in the cache if a transaction is rolled back (have a look at StandardStore). ouch, didn't know that. So the store must be transaction-aware. Olli has implemented transactional caching in extended store, this is the way to go. Good, so we should get rid of the stores that do not support this. Not only place them into the "attic/scratchpad" but kill them completely, or users might step into them since "StandardStore" seems to imply that's the way to go, but it's not. But permission caching is still broken. This is not that worse, because the cache resides in SlideToken - that means that the cache will be per user and is getting recreated every request. This should be improved. Oh, definately. Gosh, I need to dive deeper into slide to see how it works in these details. - (lateron) real XA-support to use different stores (a great feature of slide) in one transaction ah, nice. - Extendable event mechanism (that is essenital for 'inverted caching' in the presentation layer or to distribute changes in a clustered environment) big +1, what do you have in mind for this? interceptors? I will post on this issue later. The events must be transaction aware as well (some need to be sent after commit, some may be needed before to enable vetoable changes). h, synchronicity creates possible deadlocks: how would you solve the problem of a vetoable change that doesn't get vetoed nor approuved because the listener is busy, overloaded or crashed? timeouts? There should be a number of internal events and the possibility to generate custom events for example inside an interceptor. In our product we used events not only for caching, but also for synchronizing the editors swing clients by pushing events to all client. This is a very nice feature, because the client users can see in realtime what other editors do and navigation on the website can be synchronized with the clients navigation. Nice, but yeah, this is a general ability of operation observability, but I think I like passive observability more than active one. The repository is versioned and workflow issues shouldn't happen thru observability directly, but thru an application layer on top of the versioned repository. - Implement fast searching capabilities (properties and full text search, perhaps using lucene) that would be cool. How pluggable is the DASL implementation? Don't know yet. At the moment the stores are responsible for search. I see. There is for example a XQuery engine in the tamino stores that can be triggered via DASL as far as I know, but this is of course not part of slide... of course, we wouldn't know what to do with it :-) - Internal link checking (so that if you check out some revision of a document that uses others you're informed and get the choice to check out the used documents in the right revision as well). I don't know, if the current content interceptor concept allows such a feature as an optional module, otherwise it should be improved to allow something like this. I would say this is application-dependent. I agree that the repository should provide the ability to implement the above functionality, but it should not be something that the repository gives you directly... otherwise you blur the line between the repository and its semantics... and this is a path I wouldn't want Slide to see going. Agreed. On the other hand I still won't drop my idea to donate our rendering/process-engine (maybe into proposals-section) and implement some demo-project to give users a better starting point and a full featured framework to implement
Re: DISCUSSION: Slide 2.0 release
On 19 Nov 2003, at 00:23, Martin Dulisch wrote: Oliver Zeigermann wrote: Stefano Mazzocchi wrote: ... About this, I thought that "Attic", as a name, is a bad idea because that conflicts with the "CVS attic" directory. I would suggest to rename it to "scratchpad" or "whiteboard" as it's done in many other ASF projects. In what respect does it conflict with the CVS attic? I thought it would be a nice name as for CVS users it might be "speaking". Other opinions? The first time Oliver proposed "Attic" I was astonished. I would prefer "scratchpad" too. The recognition when knowing other Apache projects would be higher. Attic could cause confusion with the CVS terminology. -1 to "attic" as well. using attic is confusing and could also be problematic as CVS uses it for its day to day operation. There is a reason why no other project in the ASF uses that. Ignoring this isn't really polite, IMO. -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: DISCUSSION: Slide 2.0 release
On 19 Nov 2003, at 02:36, Christopher Lenz wrote: Oliver Zeigermann wrote: Martin Holz wrote: robert burrell donkin <[EMAIL PROTECTED]> writes: i agree with stefano's observation that "whiteboard" and "scratchpad" are the more usual names for this kind of thing. aligning naming conventions isn't critical but it can help to make newbies feel at home quicker. Cocoon uses "deprecated" for old stuff and "scratchpad" for experimental stuff. So, we have "attic" for "deprecated" and "proposals" for "scratchpad" as the status quo. As I consider this merely a matter of taste let us leave it as it is unless someone - especially committers - have serious objections :) I'm only an inactive committer, so take this as a "non-binding objection". I don't see a need to have both a "scratchpad" area as well as an area for deprecated, no longer maintained code. Sure, code with an uncertain future should go into a "scratchpad", although I'd personally just use the already existing "proposals" directory, instead of introducing more fragmentation and thus confusion. But to move dead code into a special "deprecated" or "attic" directory seems silly to me. CVS already has an attic, so why not just move dead code into it? Just cvs-delete it. It can still be retrieved by anyone who really wants to. And it doesn't pollute local copies with stuff that nobody actually wants. I find myself agreeing 100% with this proposal: if the code is dead, kill it, we can resort it later if really needed and it gets out of the users's way. As for using "proposals" instead of adding "scratchpad" I agree as well: proposal is normally used for internal forks or for big things, while scratchpad/whiteboard is used for little thing, like single classes or things... but it doesn't make sense in Slide to differentiate so I think using "proposal" for this is just fine. -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: DISCUSSION: Slide 2.0 release
Christopher Lenz wrote: Oliver Zeigermann wrote: Martin Holz wrote: robert burrell donkin <[EMAIL PROTECTED]> writes: i agree with stefano's observation that "whiteboard" and "scratchpad" are the more usual names for this kind of thing. aligning naming conventions isn't critical but it can help to make newbies feel at home quicker. Cocoon uses "deprecated" for old stuff and "scratchpad" for experimental stuff. So, we have "attic" for "deprecated" and "proposals" for "scratchpad" as the status quo. As I consider this merely a matter of taste let us leave it as it is unless someone - especially committers - have serious objections :) I'm only an inactive committer, so take this as a "non-binding objection". Well, your objection is more than a simple matter of taste, but is substantial and thus a serious objections. Thanks! I don't see a need to have both a "scratchpad" area as well as an area for deprecated, no longer maintained code. Sure, code with an uncertain future should go into a "scratchpad", although I'd personally just use the already existing "proposals" directory, instead of introducing more fragmentation and thus confusion. Agreed. But to move dead code into a special "deprecated" or "attic" directory seems silly to me. CVS already has an attic, so why not just move dead code into it? Just cvs-delete it. It can still be retrieved by anyone who really wants to. And it doesn't pollute local copies with stuff that nobody actually wants. This sounds very reasonable. My initial idea for having a special attic was not to step on anybodies toes. But I agree now... Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Oliver Zeigermann wrote: Martin Holz wrote: robert burrell donkin <[EMAIL PROTECTED]> writes: i agree with stefano's observation that "whiteboard" and "scratchpad" are the more usual names for this kind of thing. aligning naming conventions isn't critical but it can help to make newbies feel at home quicker. Cocoon uses "deprecated" for old stuff and "scratchpad" for experimental stuff. So, we have "attic" for "deprecated" and "proposals" for "scratchpad" as the status quo. As I consider this merely a matter of taste let us leave it as it is unless someone - especially committers - have serious objections :) I'm only an inactive committer, so take this as a "non-binding objection". I don't see a need to have both a "scratchpad" area as well as an area for deprecated, no longer maintained code. Sure, code with an uncertain future should go into a "scratchpad", although I'd personally just use the already existing "proposals" directory, instead of introducing more fragmentation and thus confusion. But to move dead code into a special "deprecated" or "attic" directory seems silly to me. CVS already has an attic, so why not just move dead code into it? Just cvs-delete it. It can still be retrieved by anyone who really wants to. And it doesn't pollute local copies with stuff that nobody actually wants. -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Am Mittwoch, 19. November 2003 09:23 schrieb Martin Dulisch: > Oliver Zeigermann wrote: > > Stefano Mazzocchi wrote: > > ... > > >> About this, I thought that "Attic", as a name, is a bad idea > >> because > >> that conflicts with the "CVS attic" directory. I would > >> suggest to rename it to "scratchpad" or "whiteboard" as it's > >> done in many other ASF projects. > > > > In what respect does it conflict with the CVS attic? I thought > > it would > > be a nice name as for CVS users it might be "speaking". > > > > Other opinions? > > The first time Oliver proposed "Attic" I was astonished. I would > prefer "scratchpad" too. I think 'scratchpad' is no good, because it doesn't reflect that this parts of the project should not be used anymore. For me 'attic' is ok, but 'deprecated' would have been parhaps a better choice to make it compliant with cocoon. The recognition when knowing other > Apache projects would be higher. Attic could cause confusion with > the CVS terminology. > > Martin > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Oliver Zeigermann wrote: > Stefano Mazzocchi wrote: > ... >> >> >> About this, I thought that "Attic", as a name, is a bad idea >> because >> that conflicts with the "CVS attic" directory. I would >> suggest to rename it to "scratchpad" or "whiteboard" as it's >> done in many other ASF projects. > > In what respect does it conflict with the CVS attic? I thought > it would > be a nice name as for CVS users it might be "speaking". > > Other opinions? > The first time Oliver proposed "Attic" I was astonished. I would prefer "scratchpad" too. The recognition when knowing other Apache projects would be higher. Attic could cause confusion with the CVS terminology. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Martin Holz wrote: robert burrell donkin <[EMAIL PROTECTED]> writes: i agree with stefano's observation that "whiteboard" and "scratchpad" are the more usual names for this kind of thing. aligning naming conventions isn't critical but it can help to make newbies feel at home quicker. Cocoon uses "deprecated" for old stuff and "scratchpad" for experimental stuff. So, we have "attic" for "deprecated" and "proposals" for "scratchpad" as the status quo. As I consider this merely a matter of taste let us leave it as it is unless someone - especially committers - have serious objections :) Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
robert burrell donkin <[EMAIL PROTECTED]> writes: > i agree with stefano's observation that "whiteboard" and "scratchpad" > are the more usual names for this kind of thing. aligning naming > conventions isn't critical but it can help to make newbies feel at > home quicker. Cocoon uses "deprecated" for old stuff and "scratchpad" for experimental stuff. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
On 18 Nov 2003, at 19:01, Oliver Zeigermann wrote: Stefano Mazzocchi wrote: On 18 Nov 2003, at 01:56, Oliver Zeigermann wrote: I have set up an attic section where dead code can be moved to (and of course moved back if it comes to life again for whatever reason). Currently, it is empty... About this, I thought that "Attic", as a name, is a bad idea because that conflicts with the "CVS attic" directory. I would suggest to rename it to "scratchpad" or "whiteboard" as it's done in many other ASF projects. In what respect does it conflict with the CVS attic? I thought it would be a nice name as for CVS users it might be "speaking". it's a nice name but it's already taken by the creators of cvs (in mindspace terms, at least ;) from a technical perspective, i'd guess that it'd be fine on capitalization respecting platforms but i suspect that it will cause some difficulties on filesystems which do not respect capitalization. Other opinions? i agree with stefano's observation that "whiteboard" and "scratchpad" are the more usual names for this kind of thing. aligning naming conventions isn't critical but it can help to make newbies feel at home quicker. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Stefano Mazzocchi wrote: On 18 Nov 2003, at 01:56, Oliver Zeigermann wrote: Stefano Mazzocchi wrote: bad marketing - I believe Slide has currently a major bug in its own self-marketing: no matter how you look at it, Slide is *NOT* a content management system. Probably Remy (or Yassaf/Keith/Ismael don't know who came up with this) didn't know what a content management system was, but one thing is for sure: Slide is a content repository not a content management system. Citing from http://jakarta.apache.org/slide/index.html: The Slide project main module is a Content Management and Integration System, which can be seen as a low-level content management framework. Conceptually, it provides a hierarchical organization of binary content which can be stored into arbitrary, heterogenous, distributed data stores. In addition, Slide integrates security, locking, versioning, as well as many other services. Summary: "Slide is a low-level content management framework". Doesn't that fit your impression. No. Ask around this question: "how would you define a 'low-level' cmf"? then ask them "how would you define a content repository"? and see what happens. I think that "low-level CMF" is even worse marketing, since it doesn't tell users *where* this thing fits in the architecture. Think about users browsing around jakarta or the apache.org web sites. Would the above tagline tell you what to do with slide, how to use it? Slide doesn't "manage" content, it stores it and retrieves it. Different thing. Hmmm. Slide allows for storing, versioning, retrieving, searching and giving access rights to content. What is missing to say it manages content? Processing / Rendering of content? Well, that's not managing, is it? "Low-level" says you will need higher tiers, i.e. rendering / processing, to get things going. But this is my *personal* impression only :) [snip] solidification -- users that checkout the code for the first time, have a hard time understanding what parts of the code are maintained and what are not. I would like to propose a few things here: [snip] 2) separation of the life code from the dead one. For this, the suggestion is the creation of a "/scratchpad" folder in the root of the jakarta-slide CVS module and place all dead code there. Alternatively, it's possible to use the existing "/proposal" folder. Candidates for dead code consideration are: a) the unmaintained stores b) the GUI for the webdav client I have set up an attic section where dead code can be moved to (and of course moved back if it comes to life again for whatever reason). Currently, it is empty... About this, I thought that "Attic", as a name, is a bad idea because that conflicts with the "CVS attic" directory. I would suggest to rename it to "scratchpad" or "whiteboard" as it's done in many other ASF projects. In what respect does it conflict with the CVS attic? I thought it would be a nice name as for CVS users it might be "speaking". Other opinions? build process - I think users should be able to do cvs co jakarta-slide ant ./slide and get it running. The required (non-optional) jars should be included in the download or fetched by the build script from jar repositories (the only problem seems to be JTA which is under the Sun license, so we can't put it in CVS, but the Geronimo guys already reimplemented it under the apache license, so we can use that). As I said in another post: What should be the result of such a build? Slide is not standalone, which probably is on of the reasons it is no top level project. I agree (and I suppose many people agree as well) it is desirable to have an alternative to the Tomcat environment, but I have no idea what it may look like. WAR? Can't be run like ./slide :) Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
On 18 Nov 2003, at 01:56, Oliver Zeigermann wrote: Stefano Mazzocchi wrote: bad marketing - I believe Slide has currently a major bug in its own self-marketing: no matter how you look at it, Slide is *NOT* a content management system. Probably Remy (or Yassaf/Keith/Ismael don't know who came up with this) didn't know what a content management system was, but one thing is for sure: Slide is a content repository not a content management system. Citing from http://jakarta.apache.org/slide/index.html: The Slide project main module is a Content Management and Integration System, which can be seen as a low-level content management framework. Conceptually, it provides a hierarchical organization of binary content which can be stored into arbitrary, heterogenous, distributed data stores. In addition, Slide integrates security, locking, versioning, as well as many other services. Summary: "Slide is a low-level content management framework". Doesn't that fit your impression. No. Ask around this question: "how would you define a 'low-level' cmf"? then ask them "how would you define a content repository"? and see what happens. I think that "low-level CMF" is even worse marketing, since it doesn't tell users *where* this thing fits in the architecture. Think about users browsing around jakarta or the apache.org web sites. Would the above tagline tell you what to do with slide, how to use it? Slide doesn't "manage" content, it stores it and retrieves it. Different thing. A CMS includes things like content authoring, content auditing, workflow management, presentation logic, *and* content repositories. The repository is only a (critical! important! vital!) piece of the CMS puzzle, but it's foolish to consider a content repository enough to implement a serious CMS. I think it's vital, for the success of a project, not to fool around with its own marketing. I would like to invite this community to discuss the "remarketing" of slide and propose "retargetting" of the project. [note: this will also make it easier to market Slide as the reference implementation of the JSR-170 in the future. FYI: I am the ASF representative for JSR-170 in the expert group] As I said, I can not see where Slide claims to be a full featured CMS... True. solidification -- users that checkout the code for the first time, have a hard time understanding what parts of the code are maintained and what are not. I would like to propose a few things here: [snip] 2) separation of the life code from the dead one. For this, the suggestion is the creation of a "/scratchpad" folder in the root of the jakarta-slide CVS module and place all dead code there. Alternatively, it's possible to use the existing "/proposal" folder. Candidates for dead code consideration are: a) the unmaintained stores b) the GUI for the webdav client I have set up an attic section where dead code can be moved to (and of course moved back if it comes to life again for whatever reason). Currently, it is empty... About this, I thought that "Attic", as a name, is a bad idea because that conflicts with the "CVS attic" directory. I would suggest to rename it to "scratchpad" or "whiteboard" as it's done in many other ASF projects. build process - I think users should be able to do cvs co jakarta-slide ant ./slide and get it running. The required (non-optional) jars should be included in the download or fetched by the build script from jar repositories (the only problem seems to be JTA which is under the Sun license, so we can't put it in CVS, but the Geronimo guys already reimplemented it under the apache license, so we can use that). As I said in another post: What should be the result of such a build? Slide is not standalone, which probably is on of the reasons it is no top level project. I agree (and I suppose many people agree as well) it is desirable to have an alternative to the Tomcat environment, but I have no idea what it may look like. WAR? -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: DISCUSSION: Slide 2.0 release -> Binary Packages to Produce
> As it seems to be clear by now there will be a 2.0 release. This > includes there will be milestone releases before the final one which > will be available as binaries *in pricipal*. > Shall we set a date? Mid January -> Release Candidate 1? > The problem for me is what a Slide binary release may look like... I > have seen the 1.0.x binary comes as a Tomcat release modified to include > Slide. As Stefano pointed out, this hardly is the way to go for the > 2.x., is it? I have also seen this 1.0.x release contains jars that > might lead to license problems... > A tomcat-wrapped binary release is nice (esp preconfigured with FileStores or hsqldb) because it provides users with a download and run WEBDAV server, they don't need to get and configure the servlet container seperately. I think this is attractive to many users. If no one else is interested, I would be happy to work on this. > Would a war (web archive) be enough for a binary release? Hardly... > I would propose generating multiple binary release packages from the slide codebase: 1) Slide/Tomcat Integrated release, preconfigured to be 'out of the box runnable' 2) Slide WEBDAV Server WAR file for Servlet Containers supporting WAR deployment, still requireing store and users configuration. 3) Slide WEBDAV Server Admin WAR file. (aside: what is the state of the admin stuff? is it worth taking into the release?) Additionally, I would remove the client into a seperate jakarta project (jakarta-slide-client). It has little to do with the server code (although I imagine the tests use it?), and might experience more development if it had its own project. Richie > Discussion is needed! > > Oliver > > Michael Smith wrote: > > > davout wrote: > > > >> Can somebody from the SLIDE development team please confirm that they > >> will > >> or will not be pushing out a binary distribution? > > > > > > In its current state, slide is not appropriate for use by people > > unwilling to work with the source. Providing binaries would, right now, > > be a disservice. > > > > The hope is that slide 2.0 (and presumably beta versions before that) > > will be provided as binaries within a relatively short period of time - > > looking at the current progress, I'd guess around 1-2 months would be a > > reasonable time to start producing betas. > > > > Mike > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > . > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --- This mail sent through the ungerground webmail system - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Hi! Lets move the stuff from src/contrib/webdavui into the Attic, since it does not build with current commons-httpclient, and no active part of slide requires it. I am not a committer, so I cannot move anything... Richie Quoting Oliver Zeigermann <[EMAIL PROTECTED]>: > Stefano Mazzocchi wrote: > > I think we need a little plan of action. (of course, since I'm not an > > active committer, I don't get to vote, but at least I'll share some of > > my experience in these things). > > > > new generation number > > - > > > > From a user perspective, Slide appeared dead for too long. Doing a > > release with a 2.0 number will give the impression that things are > > changing on this regard and it's a thing that people will like, even if > > the architecture hasn't changed. > > This is what everybody thought, right? > > > > > bad marketing > > - > > > > I believe Slide has currently a major bug in its own self-marketing: no > > matter how you look at it, Slide is *NOT* a content management system. > > Probably Remy (or Yassaf/Keith/Ismael don't know who came up with this) > > didn't know what a content management system was, but one thing is for > > sure: Slide is a content repository not a content management system. > > Citing from http://jakarta.apache.org/slide/index.html: > > > The Slide project main module is a Content Management and Integration > > System, which can be seen as a low-level content management > > framework. Conceptually, it provides a hierarchical organization of > > binary content which can be stored into arbitrary, heterogenous, > > distributed data stores. In addition, Slide integrates security, > > locking, versioning, as well as many other services. > > Summary: "Slide is a low-level content management framework". Doesn't > that fit your impression. > > > A CMS includes things like content authoring, content auditing, workflow > > management, presentation logic, *and* content repositories. The > > repository is only a (critical! important! vital!) piece of the CMS > > puzzle, but it's foolish to consider a content repository enough to > > implement a serious CMS. > > > > I think it's vital, for the success of a project, not to fool around > > with its own marketing. > > > > I would like to invite this community to discuss the "remarketing" of > > slide and propose "retargetting" of the project. > > > > [note: this will also make it easier to market Slide as the reference > > implementation of the JSR-170 in the future. FYI: I am the ASF > > representative for JSR-170 in the expert group] > > As I said, I can not see where Slide claims to be a full featured CMS... > > > > > solidification > > -- > > > > users that checkout the code for the first time, have a hard time > > understanding what parts of the code are maintained and what are not. I > > would like to propose a few things here: > > > [snip] > > > > 2) separation of the life code from the dead one. For this, the > > suggestion is the creation of a "/scratchpad" folder in the root of the > > jakarta-slide CVS module and place all dead code there. Alternatively, > > it's possible to use the existing "/proposal" folder. Candidates for > > dead code consideration are: > > > > a) the unmaintained stores > > b) the GUI for the webdav client > > > > I have set up an attic section where dead code can be moved to (and of > course moved back if it comes to life again for whatever reason). > Currently, it is empty... > > > build process > > - > > > > I think users should be able to do > > > > cvs co jakarta-slide > > ant > > ./slide > > > > and get it running. The required (non-optional) jars should be included > > in the download or fetched by the build script from jar repositories > > (the only problem seems to be JTA which is under the Sun license, so we > > can't put it in CVS, but the Geronimo guys already reimplemented it > > under the apache license, so we can use that). > > As I said in another post: What should be the result of such a build? > Slide is not standalone, which probably is on of the reasons it is no > top level project. I agree (and I suppose many people agree as well) it > is desirable to have an alternative to the Tomcat environment, but I > have no idea what it may look like. > > Oliver > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --- This mail sent through the ungerground webmail system - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
[snip...] > > > My favorit issues are: > > - Getting the stores to work as expected (at least file/db-stores) > > this is critical, yes. > > > - Implement internal locking (should not be transactional) > > can you tell us more about this? I think we need two different types of locks in slide: First there are webdav-locks that should be acquired/released transactional. This means that it should be possible to acquire a number of locks in one transactional and rollback the whole transaction when a single lock fails. Bedides this there is a need for internal global locks that handle concurrents modifications. Think of two copy operations in different transactions where every user wants to to copy to the same target. At the moment this is delegated to underlying stores in a not very beatyful manner (recursive read)... Olli will start a thread on this to discuss this in more detail. > > > - Improve and fix caching. It's not fully transactional in some places > > and can be improved (especially lock/permission-cache) > > same here, do you have any idea on how to do this? [curious] First and most easy would be to disable caching :-) If caching is enabled, it must be ensured that the cache is always consistent. At the moment there a some places, where for example invalid data remains in the cache if a transaction is rolled back (have a look at StandardStore). So the store must be transaction-aware. Olli has implemented transactional caching in extended store, this is the way to go. But permission caching is still broken. This is not that worse, because the cache resides in SlideToken - that means that the cache will be per user and is getting recreated every request. This should be improved. > > > - (lateron) real XA-support to use different stores (a great feature of > > slide) in one transaction > > ah, nice. > > > - Extendable event mechanism (that is essenital for 'inverted caching' in > > the presentation layer or to distribute changes in a clustered > > environment) > > big +1, what do you have in mind for this? interceptors? I will post on this issue later. The events must be transaction aware as well (some need to be sent after commit, some may be needed before to enable vetoable changes). There should be a number of internal events and the possibility to generate custom events for example inside an interceptor. In our product we used events not only for caching, but also for synchronizing the editors swing clients by pushing events to all client. This is a very nice feature, because the client users can see in realtime what other editors do and navigation on the website can be synchronized with the clients navigation. > > > - Implement fast searching capabilities (properties and full text search, > > perhaps using lucene) > > that would be cool. How pluggable is the DASL implementation? Don't know yet. At the moment the stores are responsible for search. There is for example a XQuery engine in the tamino stores that can be triggered via DASL as far as I know, but this is of course not part of slide... > > > - Internal link checking (so that if you check out some revision of a > > document that uses others you're informed and get the choice to check out > > the used documents in the right revision as well). I don't know, if the > > current content interceptor concept allows such a feature as an optional > > module, otherwise it should be improved to allow something like this. > > I would say this is application-dependent. I agree that the repository > should provide the ability to implement the above functionality, but it > should not be something that the repository gives you directly... > otherwise you blur the line between the repository and its semantics... > and this is a path I wouldn't want Slide to see going. Agreed. > > > On the other hand I still won't drop my idea to donate our > > rendering/process-engine (maybe into proposals-section) and implement > > some demo-project to give users a better starting point and a full > > featured framework to implement projects. But I see that this have to be > > discussed. > > I say we focus on getting the repository out solid, fast and clean, then > we'll see what happens. Yes, but personally I'm responsible for providing a CMS product wich is used in our company. So I have to care about the other things as well and can't distribute that much at the moment... Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Chritopher, thanks a lot! That's what I was looking for! Oliver Christopher Lenz wrote: Hi Oliver, the actual source for the docs are in [src/doc], and are XSL-transformed by the Ant "doc" target into the [docs] directory. IIRC, the whole process is: - modify the documents in [src/doc] - make the transformation using "ant doc" - commit the changes in the [docs] directory - login in to jakarta.apache.org and checkout/update the [docs] directory into the appropriate directory on the web server. Make sure the permissions are correct, preferrably by setting your umask to 022 before doing the cvs co/update. HTH, -chris Oliver Zeigermann wrote: Hi Robert, hi all, I have a hard time figuring out how to update the docs. While I seem to have found out how to actually deploy modified pages on the web server I suspect, those pages in the Slide pages are not native HTML, but generated from the real source. I really tried to find out on apache.org, but actually seem to be too dump. Any hint? Thanks in advance, Oliver robert burrell donkin wrote: the dev list is usually considered the right place for discussions about releases. certainly, all VOTEs must take place on the dev list. any release will mean several VOTEs usually starting with a release plan and the election (often by lazy acclamation) of the release manager. so, it's probably best to invite anyone from the user list who's interested over to the dev (rather than vice-versa). - robert On 13 Nov 2003, at 15:29, Oliver Zeigermann wrote: For everyone subscribed to the dev list only: Discussion about the new release has been started in the user list. Please keep the discussion in that list. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Hi Oliver, the actual source for the docs are in [src/doc], and are XSL-transformed by the Ant "doc" target into the [docs] directory. IIRC, the whole process is: - modify the documents in [src/doc] - make the transformation using "ant doc" - commit the changes in the [docs] directory - login in to jakarta.apache.org and checkout/update the [docs] directory into the appropriate directory on the web server. Make sure the permissions are correct, preferrably by setting your umask to 022 before doing the cvs co/update. HTH, -chris Oliver Zeigermann wrote: Hi Robert, hi all, I have a hard time figuring out how to update the docs. While I seem to have found out how to actually deploy modified pages on the web server I suspect, those pages in the Slide pages are not native HTML, but generated from the real source. I really tried to find out on apache.org, but actually seem to be too dump. Any hint? Thanks in advance, Oliver robert burrell donkin wrote: the dev list is usually considered the right place for discussions about releases. certainly, all VOTEs must take place on the dev list. any release will mean several VOTEs usually starting with a release plan and the election (often by lazy acclamation) of the release manager. so, it's probably best to invite anyone from the user list who's interested over to the dev (rather than vice-versa). - robert On 13 Nov 2003, at 15:29, Oliver Zeigermann wrote: For everyone subscribed to the dev list only: Discussion about the new release has been started in the user list. Please keep the discussion in that list. Oliver -- Christopher Lenz /=/ cmlenz at gmx.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Hi Robert, hi all, I have a hard time figuring out how to update the docs. While I seem to have found out how to actually deploy modified pages on the web server I suspect, those pages in the Slide pages are not native HTML, but generated from the real source. I really tried to find out on apache.org, but actually seem to be too dump. Any hint? Thanks in advance, Oliver robert burrell donkin wrote: the dev list is usually considered the right place for discussions about releases. certainly, all VOTEs must take place on the dev list. any release will mean several VOTEs usually starting with a release plan and the election (often by lazy acclamation) of the release manager. so, it's probably best to invite anyone from the user list who's interested over to the dev (rather than vice-versa). - robert On 13 Nov 2003, at 15:29, Oliver Zeigermann wrote: For everyone subscribed to the dev list only: Discussion about the new release has been started in the user list. Please keep the discussion in that list. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Stefano Mazzocchi wrote: I think we need a little plan of action. (of course, since I'm not an active committer, I don't get to vote, but at least I'll share some of my experience in these things). new generation number - From a user perspective, Slide appeared dead for too long. Doing a release with a 2.0 number will give the impression that things are changing on this regard and it's a thing that people will like, even if the architecture hasn't changed. This is what everybody thought, right? bad marketing - I believe Slide has currently a major bug in its own self-marketing: no matter how you look at it, Slide is *NOT* a content management system. Probably Remy (or Yassaf/Keith/Ismael don't know who came up with this) didn't know what a content management system was, but one thing is for sure: Slide is a content repository not a content management system. Citing from http://jakarta.apache.org/slide/index.html: The Slide project main module is a Content Management and Integration System, which can be seen as a low-level content management framework. Conceptually, it provides a hierarchical organization of binary content which can be stored into arbitrary, heterogenous, distributed data stores. In addition, Slide integrates security, locking, versioning, as well as many other services. Summary: "Slide is a low-level content management framework". Doesn't that fit your impression. A CMS includes things like content authoring, content auditing, workflow management, presentation logic, *and* content repositories. The repository is only a (critical! important! vital!) piece of the CMS puzzle, but it's foolish to consider a content repository enough to implement a serious CMS. I think it's vital, for the success of a project, not to fool around with its own marketing. I would like to invite this community to discuss the "remarketing" of slide and propose "retargetting" of the project. [note: this will also make it easier to market Slide as the reference implementation of the JSR-170 in the future. FYI: I am the ASF representative for JSR-170 in the expert group] As I said, I can not see where Slide claims to be a full featured CMS... solidification -- users that checkout the code for the first time, have a hard time understanding what parts of the code are maintained and what are not. I would like to propose a few things here: [snip] 2) separation of the life code from the dead one. For this, the suggestion is the creation of a "/scratchpad" folder in the root of the jakarta-slide CVS module and place all dead code there. Alternatively, it's possible to use the existing "/proposal" folder. Candidates for dead code consideration are: a) the unmaintained stores b) the GUI for the webdav client I have set up an attic section where dead code can be moved to (and of course moved back if it comes to life again for whatever reason). Currently, it is empty... build process - I think users should be able to do cvs co jakarta-slide ant ./slide and get it running. The required (non-optional) jars should be included in the download or fetched by the build script from jar repositories (the only problem seems to be JTA which is under the Sun license, so we can't put it in CVS, but the Geronimo guys already reimplemented it under the apache license, so we can use that). As I said in another post: What should be the result of such a build? Slide is not standalone, which probably is on of the reasons it is no top level project. I agree (and I suppose many people agree as well) it is desirable to have an alternative to the Tomcat environment, but I have no idea what it may look like. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
As it seems to be clear by now there will be a 2.0 release. This includes there will be milestone releases before the final one which will be available as binaries *in pricipal*. The problem for me is what a Slide binary release may look like... I have seen the 1.0.x binary comes as a Tomcat release modified to include Slide. As Stefano pointed out, this hardly is the way to go for the 2.x., is it? I have also seen this 1.0.x release contains jars that might lead to license problems... Would a war (web archive) be enough for a binary release? Hardly... Discussion is needed! Oliver Michael Smith wrote: > davout wrote: > >> Can somebody from the SLIDE development team please confirm that they >> will >> or will not be pushing out a binary distribution? > > > In its current state, slide is not appropriate for use by people > unwilling to work with the source. Providing binaries would, right now, > be a disservice. > > The hope is that slide 2.0 (and presumably beta versions before that) > will be provided as binaries within a relatively short period of time - > looking at the current progress, I'd guess around 1-2 months would be a > reasonable time to start producing betas. > > Mike > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > . > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Daniel Florey wrote: It's nice to have you around on this list Stefano, you're able to point out things very clearly. Thanks. I'm propagating the idea of moving from a CMS to something like a CMF in our company for quite a while. But I think that Slide should be more than just a content repository. If we don't provide some bundled CMS build on top of slide (JSP-based, Cocoon-based or whatever), many people don't see the potential of Slide. Very true, but wheter or not this is Slide's direct concern, this is another story. It would be like saying that you have to ship Tomcat with a big servlet (say Cocoon) otherwise people would not understand the power of servlets. I think it's better to have each project focus on what they do best (repository for Slide) and let others build applications with it. This is called "separation of concerns". It allows faster parallelization and increases scalability of the entirey development process. But first we have to get Slide running as a content repository and it's still a way to go. Yes. I think this is what we should focus on. The community, out of environmental pressure, will decide what to do later. My favorit issues are: - Getting the stores to work as expected (at least file/db-stores) this is critical, yes. - Implement internal locking (should not be transactional) can you tell us more about this? - Improve and fix caching. It's not fully transactional in some places and can be improved (especially lock/permission-cache) same here, do you have any idea on how to do this? [curious] - (lateron) real XA-support to use different stores (a great feature of slide) in one transaction ah, nice. - Extendable event mechanism (that is essenital for 'inverted caching' in the presentation layer or to distribute changes in a clustered environment) big +1, what do you have in mind for this? interceptors? - Implement fast searching capabilities (properties and full text search, perhaps using lucene) that would be cool. How pluggable is the DASL implementation? - Internal link checking (so that if you check out some revision of a document that uses others you're informed and get the choice to check out the used documents in the right revision as well). I don't know, if the current content interceptor concept allows such a feature as an optional module, otherwise it should be improved to allow something like this. I would say this is application-dependent. I agree that the repository should provide the ability to implement the above functionality, but it should not be something that the repository gives you directly... otherwise you blur the line between the repository and its semantics... and this is a path I wouldn't want Slide to see going. On the other hand I still won't drop my idea to donate our rendering/process-engine (maybe into proposals-section) and implement some demo-project to give users a better starting point and a full featured framework to implement projects. But I see that this have to be discussed. I say we focus on getting the repository out solid, fast and clean, then we'll see what happens. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
> >> > >> A CMS includes things like content authoring, content auditing, > >> workflow management, presentation logic, *and* content repositories. > >> The repository is only a (critical! important! vital!) piece of the > >> CMS > >> puzzle, but it's foolish to consider a content repository enough to > >> implement a serious CMS. > > > > This is true for the current stage of development but we hope to get > > this > > features in the future. We will port our process engine (for rendering > > and > > workflow management) to slide and are going to donate it to the slide > > project > > if the public likes it. > > So I think it should still remain under the flag of CMS. > > I humbly yet strongly disagree. Both presentation logic and workflow > management are things that are almost impossible to standardize. Those > who tried failed rather miserably in the market. > > All commercial CMS vendors and the major open source CMSs (Zope, for > example), are moving away from a CMS toward a CMF (content management > framework), a toolkit where the frontend/repository/backend stages are > clearly separate (and interoperable!) and the various pieces can be > changed independently. > > I think it would be silly for slide to do the exact opposite. It's nice to have you around on this list Stefano, you're able to point out things very clearly. I'm propagating the idea of moving from a CMS to something like a CMF in our company for quite a while. But I think that Slide should be more than just a content repository. If we don't provide some bundled CMS build on top of slide (JSP-based, Cocoon-based or whatever), many people don't see the potential of Slide. But first we have to get Slide running as a content repository and it's still a way to go. My favorit issues are: - Getting the stores to work as expected (at least file/db-stores) - Implement internal locking (should not be transactional) - Improve and fix caching. It's not fully transactional in some places and can be improved (especially lock/permission-cache) - (lateron) real XA-support to use different stores (a great feature of slide) in one transaction - Extendable event mechanism (that is essenital for 'inverted caching' in the presentation layer or to distribute changes in a clustered environment) - Implement fast searching capabilities (properties and full text search, perhaps using lucene) - Internal link checking (so that if you check out some revision of a document that uses others you're informed and get the choice to check out the used documents in the right revision as well). I don't know, if the current content interceptor concept allows such a feature as an optional module, otherwise it should be improved to allow something like this. On the other hand I still won't drop my idea to donate our rendering/process-engine (maybe into proposals-section) and implement some demo-project to give users a better starting point and a full featured framework to implement projects. But I see that this have to be discussed. Daniel > > -- > Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Well, the CVS Head should have at least integration quality, if not production, IMHO. How is anyone supposed to get things running if it the HEAD represents some undeterminate development state? Whether the build/run should be as simple as stefano describes is another question... Richie On Sat, 2003-11-15 at 00:47, Oliver Zeigermann wrote: > Stefano Mazzocchi wrote: > > I think users should be able to do > > > > cvs co jakarta-slide > > ant > > ./slide > > > > and get it running. The required (non-optional) jars should be included > > in the download or fetched by the build script from jar repositories > > (the only problem seems to be JTA which is under the Sun license, so we > > can't put it in CVS, but the Geronimo guys already reimplemented it > > under the apache license, so we can use that). > > I disagree. If we finally have a release why would any *user* want to do > this? On the other side: I have seen so much branching and even > painfully merged part of it myself, partly because people seem to be > afraid to contribute their stuff publicly. If people get the impression > everything that is in the CVS HEAD needs to be in production quality > valuable contributions might be deterred. > > Oliver > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > signature.asc Description: This is a digitally signed message part
Re: DISCUSSION: Slide 2.0 release
On Sat, 2003-11-15 at 01:05, Stefano Mazzocchi wrote: > On 15 Nov 2003, at 00:47, Oliver Zeigermann wrote: > > > Stefano Mazzocchi wrote: > >> I think users should be able to do > >> cvs co jakarta-slide > >> ant > >> ./slide > >> and get it running. The required (non-optional) jars should be > >> included in the download or fetched by the build script from jar > >> repositories (the only problem seems to be JTA which is under the Sun > >> license, so we can't put it in CVS, but the Geronimo guys already > >> reimplemented it under the apache license, so we can use that). > > > > I disagree. If we finally have a release why would any *user* want to > > do this? > > because they download the binary distribution, then find a bug, then > checkout the CVS module, then build. > > If the build is not piece of cake, those guys will simply not continue > and you loose yet another potential committer. Look around: you'll see > that the simplicity of CVS building is directly proportional to the > number of active committers that that project has. It's a cause, not an > effect. > > > On the other side: I have seen so much branching and even painfully > > merged part of it myself, partly because people seem to be afraid to > > contribute their stuff publicly. If people get the impression > > everything that is in the CVS HEAD needs to be in production quality > > valuable contributions might be deterred. > > Nah, slide is highly modular, you can plugin your new stuff without > breaking anything (as you are doing with the new stores). > > At the same time, if you change something that is core, this *must* be > kept in production quality mode. that is: you should always do a clean > build and pass the unit tests before committing. > > using strict checking for core and looser checking for pluggable stuff > will give you solidity and ease of innovation, without sacrificing one > for the other. > This sounds highly reasonable! > -- > Stefano. signature.asc Description: This is a digitally signed message part
Re: DISCUSSION: Slide 2.0 release
Mike Oliver wrote: #1 I believe it is less than desireable to require jars to be moved out of the webapp and into Tomcat's commons for a lot of reasons, not the least of which is the compatibility of other webapps and classpath problems (with other webapps on that same Tomcat) you introduce by putting Slide jars in Tomcat commons. The WEB-INF/lib is the more desireable place for the Slide jars including Slide-Admin (IMHO). It is not required to move jars. You can just deploy the war. Done this with Tomcat and Weblogic and it actually works. But when you want to integrate Slide more tightly, e.g. to make the container use Slide autehtication, a web application it not enough. Mainly for class loader issues certains Slide classes must be put into the path for the kernel class loader. So, it's the other way round: class loader problems are the reason for moving jars around. As this class loader scenario seen in Tomcat and all other containers I know makes a lot of sense - even if it bothers us in this special case - there is no way to get rid of jar moving for tight integration. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Stefano hit the nail on the head with "Look around". I believe that there are at least three "requirements" for the Slide 2.0 release and other enhancements that will make Slide much more attractive and therefore attract many more talented people to contribute which is what we all want to see. Requirements #1 (not necessarily most important). Downloadable binaries that will run with minimal manual steps. #2 Current and thorough Installation and Deployment Documentation. Slide-Admin needs more than one paragraph and RUNNNG.txt doesn't even have the current directory references. #3 Distribution Catalog. What is in the distribution, what are the proposals, what are the examples, what are the various stores. I am volunteering to do/help with #2 and #3. Enhancements #1 I believe it is less than desireable to require jars to be moved out of the webapp and into Tomcat's commons for a lot of reasons, not the least of which is the compatibility of other webapps and classpath problems (with other webapps on that same Tomcat) you introduce by putting Slide jars in Tomcat commons. The WEB-INF/lib is the more desireable place for the Slide jars including Slide-Admin (IMHO). #2 What about a Struts Application "Front End" to the Slide content? I see lots of components that are aimed at that, but I am sure many of the members of the Slide community have built their own. Perhaps someone will contribute??? Thanks, I just synched with cvs and want to see if it will build and if I can get it running...;-) Ollie Oliver Zeigermann wrote: Stefano Mazzocchi wrote: On 15 Nov 2003, at 00:47, Oliver Zeigermann wrote: Stefano Mazzocchi wrote: I think users should be able to do cvs co jakarta-slide ant ./slide and get it running. The required (non-optional) jars should be included in the download or fetched by the build script from jar repositories (the only problem seems to be JTA which is under the Sun license, so we can't put it in CVS, but the Geronimo guys already reimplemented it under the apache license, so we can use that). Just noticed: What you describe here is the status quo anyhow, isn't it? To JTA: I wonder as it is only interfaces. Because of that, what the Geronimo people do must be identical to the stuff from Sun. This is funny, isn't it? I disagree. If we finally have a release why would any *user* want to do this? because they download the binary distribution, then find a bug, then checkout the CVS module, then build. If the build is not piece of cake, those guys will simply not continue and you loose yet another potential committer. Look around: you'll see that the simplicity of CVS building is directly proportional to the number of active committers that that project has. It's a cause, not an effect. Sounds reasonable :) On the other side: I have seen so much branching and even painfully merged part of it myself, partly because people seem to be afraid to contribute their stuff publicly. If people get the impression everything that is in the CVS HEAD needs to be in production quality valuable contributions might be deterred. Nah, slide is highly modular, you can plugin your new stuff without breaking anything (as you are doing with the new stores). At the same time, if you change something that is core, this *must* be kept in production quality mode. that is: you should always do a clean build and pass the unit tests before committing. using strict checking for core and looser checking for pluggable stuff will give you solidity and ease of innovation, without sacrificing one for the other. We agree on this! Of course no one should break the build! Also, you should not check in stuff into the kernel that does not work, but this is not all that easy (while the first item is ;). I just wanted to make clear there *must be* a difference between CVS HEAD and a release in terms of quality and stability and this must be clear to everyone. That's all :) Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Stefano Mazzocchi wrote: On 15 Nov 2003, at 00:47, Oliver Zeigermann wrote: Stefano Mazzocchi wrote: I think users should be able to do cvs co jakarta-slide ant ./slide and get it running. The required (non-optional) jars should be included in the download or fetched by the build script from jar repositories (the only problem seems to be JTA which is under the Sun license, so we can't put it in CVS, but the Geronimo guys already reimplemented it under the apache license, so we can use that). Just noticed: What you describe here is the status quo anyhow, isn't it? To JTA: I wonder as it is only interfaces. Because of that, what the Geronimo people do must be identical to the stuff from Sun. This is funny, isn't it? I disagree. If we finally have a release why would any *user* want to do this? because they download the binary distribution, then find a bug, then checkout the CVS module, then build. If the build is not piece of cake, those guys will simply not continue and you loose yet another potential committer. Look around: you'll see that the simplicity of CVS building is directly proportional to the number of active committers that that project has. It's a cause, not an effect. Sounds reasonable :) On the other side: I have seen so much branching and even painfully merged part of it myself, partly because people seem to be afraid to contribute their stuff publicly. If people get the impression everything that is in the CVS HEAD needs to be in production quality valuable contributions might be deterred. Nah, slide is highly modular, you can plugin your new stuff without breaking anything (as you are doing with the new stores). At the same time, if you change something that is core, this *must* be kept in production quality mode. that is: you should always do a clean build and pass the unit tests before committing. using strict checking for core and looser checking for pluggable stuff will give you solidity and ease of innovation, without sacrificing one for the other. We agree on this! Of course no one should break the build! Also, you should not check in stuff into the kernel that does not work, but this is not all that easy (while the first item is ;). I just wanted to make clear there *must be* a difference between CVS HEAD and a release in terms of quality and stability and this must be clear to everyone. That's all :) Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
On 15 Nov 2003, at 00:47, Oliver Zeigermann wrote: Stefano Mazzocchi wrote: I think users should be able to do cvs co jakarta-slide ant ./slide and get it running. The required (non-optional) jars should be included in the download or fetched by the build script from jar repositories (the only problem seems to be JTA which is under the Sun license, so we can't put it in CVS, but the Geronimo guys already reimplemented it under the apache license, so we can use that). I disagree. If we finally have a release why would any *user* want to do this? because they download the binary distribution, then find a bug, then checkout the CVS module, then build. If the build is not piece of cake, those guys will simply not continue and you loose yet another potential committer. Look around: you'll see that the simplicity of CVS building is directly proportional to the number of active committers that that project has. It's a cause, not an effect. On the other side: I have seen so much branching and even painfully merged part of it myself, partly because people seem to be afraid to contribute their stuff publicly. If people get the impression everything that is in the CVS HEAD needs to be in production quality valuable contributions might be deterred. Nah, slide is highly modular, you can plugin your new stuff without breaking anything (as you are doing with the new stores). At the same time, if you change something that is core, this *must* be kept in production quality mode. that is: you should always do a clean build and pass the unit tests before committing. using strict checking for core and looser checking for pluggable stuff will give you solidity and ease of innovation, without sacrificing one for the other. -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: DISCUSSION: Slide 2.0 release
Stefano Mazzocchi wrote: I think users should be able to do cvs co jakarta-slide ant ./slide and get it running. The required (non-optional) jars should be included in the download or fetched by the build script from jar repositories (the only problem seems to be JTA which is under the Sun license, so we can't put it in CVS, but the Geronimo guys already reimplemented it under the apache license, so we can use that). I disagree. If we finally have a release why would any *user* want to do this? On the other side: I have seen so much branching and even painfully merged part of it myself, partly because people seem to be afraid to contribute their stuff publicly. If people get the impression everything that is in the CVS HEAD needs to be in production quality valuable contributions might be deterred. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
On 14 Nov 2003, at 18:41, Remy Maucherat wrote: \bad marketing - I believe Slide has currently a major bug in its own self-marketing: no matter how you look at it, Slide is *NOT* a content management system. Probably Remy (or Yassaf/Keith/Ismael don't know who came up with this) It's Assaf, not Yassaf. D'oh! you're totally right. My bad. didn't know what a content management system was, but one thing is for sure: Slide is a content repository not a content management system. A CMS includes things like content authoring, content auditing, workflow management, presentation logic, *and* content repositories. The repository is only a (critical! important! vital!) piece of the CMS puzzle, but it's foolish to consider a content repository enough to implement a serious CMS. I think it's vital, for the success of a project, not to fool around with its own marketing. I would like to invite this community to discuss the "remarketing" of slide and propose "retargetting" of the project. [note: this will also make it easier to market Slide as the reference implementation of the JSR-170 in the future. FYI: I am the ASF representative for JSR-170 in the expert group] The original plan was to have many CMS features, such as workflow and a complete web interface on top of that, but there weren't enough resources (M$ did that and called it Sharepoint). That's the reason for the "marketting". I see. Thanks for sharing the history bits. -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: DISCUSSION: Slide 2.0 release
Stefano Mazzocchi wrote: On 14 Nov 2003, at 08:23, Oliver Zeigermann wrote: [COPIED FROM USERS LIST, THIS IS HERE IN THE DEV LIST IS THE RIGHT POST TO FOLLOW UP] Hi everyone! Hi! I understand those votes from active committers which are +1 from Martin +1 from Ingo +1 from Peter mean: 1. We actually should start a release process now that's great, but I think we should outline a list of showstoppers and decide what to do, see below for an attemp on that list. 2. I should be the release manager sounds good to me. Apache is a do-ocracy: who volunteers get the power (also the blame or the fame, whichever comes first ;-) If this is common understanding I'd like to start by discussing open issues in follow up posts. So, while others are welcome to start follow up threads, please restrict yourself to the topic of discussing this release in these follow ups. To the current status: I am optimistic I will get an acount and be granted commit access soon, as recent email communication with the PMC indicate this. As soon as this happens I will commit all my patches (only concerning stores, so do not worry and will also present the current status of the merged J2EE/JDBC store for public review. As soon as the store is more or less stable I will adapt both this one and the file store to the new ACL implementation (provided adaption is needed). I am too chicken-hearted to check the new ACL stuff out, before having fixed the store Yeah, one thing at the time. That's it for now, details in the follow ups. I think we need a little plan of action. (of course, since I'm not an active committer, I don't get to vote, but at least I'll share some of my experience in these things). new generation number - From a user perspective, Slide appeared dead for too long. Doing a release with a 2.0 number will give the impression that things are changing on this regard and it's a thing that people will like, even if the architecture hasn't changed. bad marketing - I believe Slide has currently a major bug in its own self-marketing: no matter how you look at it, Slide is *NOT* a content management system. Probably Remy (or Yassaf/Keith/Ismael don't know who came up with this) It's Assaf, not Yassaf. didn't know what a content management system was, but one thing is for sure: Slide is a content repository not a content management system. A CMS includes things like content authoring, content auditing, workflow management, presentation logic, *and* content repositories. The repository is only a (critical! important! vital!) piece of the CMS puzzle, but it's foolish to consider a content repository enough to implement a serious CMS. I think it's vital, for the success of a project, not to fool around with its own marketing. I would like to invite this community to discuss the "remarketing" of slide and propose "retargetting" of the project. [note: this will also make it easier to market Slide as the reference implementation of the JSR-170 in the future. FYI: I am the ASF representative for JSR-170 in the expert group] The original plan was to have many CMS features, such as workflow and a complete web interface on top of that, but there weren't enough resources (M$ did that and called it Sharepoint). That's the reason for the "marketting". Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Stefano Mazzocchi wrote: [snip] 1) clear separation of the server part from the client part. When you download the slide CVS, you get server and client at the same time, with the same build, docs and all that. I think we should clearly separate those things out. Potentially, in the future, Slide could become a "top level" ASF project (think slide.apache.org) and we might further change into slide-server and slide-client as CVS modules. I think separation will increase the ability for others to get in and help. [snip] As a very occassional participant in this list, all I've been interested in so far has been the client side libraries. I would love to see these split out into a separate build, posted separately for download (and possible even on a different release schedule). I daresay, I've thought about suggesting to this list that all of the "methods" that are extensions of the HttpClient library ought to move over to the HttpClient library instead, perhaps as part of the "contrib" folder there. That way, they'd be versioned with HttpClient instead, which might be more appropriate. I mention that in passing, though. I'm not sure whether it is a good idea. Anyway, I'm glad that someone else mentioned rethinking the treatment of the "client" side, as I think some small changes there might make it dramatically easier to use and keep up with, and keep up-to-date with HttpClient. -Eric. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
On 14 Nov 2003, at 17:07, Daniel Florey wrote: Hi, as slide seems to gain more and more interest over the last weeks I'd like to add some comments to this issue. appreciated. Our company has implemented a full featured CMS in the past few years that works with a self implemented content repository. Beside the repository we implemented a presentation layer (with some kind of 'inverted caching' as Stefano calls it) that generates web pages on the fly, a workflow engine and event handling to enable distributed updates of the presentation caches and the clients and other things required by a CMS. Welcome to the club! :-) It seems like everybody and their sisters did that. As the numbers of CMS available is growing it is hard to stay in business with a non open source cms. So we decided to drop parts of our own server development and started to support slide. Yep. bad marketing - I believe Slide has currently a major bug in its own self-marketing: no matter how you look at it, Slide is *NOT* a content management system. Probably Remy (or Yassaf/Keith/Ismael don't know who came up with this) didn't know what a content management system was, but one thing is for sure: Slide is a content repository not a content management system. A CMS includes things like content authoring, content auditing, workflow management, presentation logic, *and* content repositories. The repository is only a (critical! important! vital!) piece of the CMS puzzle, but it's foolish to consider a content repository enough to implement a serious CMS. This is true for the current stage of development but we hope to get this features in the future. We will port our process engine (for rendering and workflow management) to slide and are going to donate it to the slide project if the public likes it. So I think it should still remain under the flag of CMS. I humbly yet strongly disagree. Both presentation logic and workflow management are things that are almost impossible to standardize. Those who tried failed rather miserably in the market. All commercial CMS vendors and the major open source CMSs (Zope, for example), are moving away from a CMS toward a CMF (content management framework), a toolkit where the frontend/repository/backend stages are clearly separate (and interoperable!) and the various pieces can be changed independently. I think it would be silly for slide to do the exact opposite. -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: DISCUSSION: Slide 2.0 release
Hi, as slide seems to gain more and more interest over the last weeks I'd like to add some comments to this issue. Our company has implemented a full featured CMS in the past few years that works with a self implemented content repository. Beside the repository we implemented a presentation layer (with some kind of 'inverted caching' as Stefano calls it) that generates web pages on the fly, a workflow engine and event handling to enable distributed updates of the presentation caches and the clients and other things required by a CMS. As the numbers of CMS available is growing it is hard to stay in business with a non open source cms. So we decided to drop parts of our own server development and started to support slide. > > > bad marketing > - > > I believe Slide has currently a major bug in its own self-marketing: no > matter how you look at it, Slide is *NOT* a content management system. > Probably Remy (or Yassaf/Keith/Ismael don't know who came up with this) > didn't know what a content management system was, but one thing is for > sure: Slide is a content repository not a content management system. > > A CMS includes things like content authoring, content auditing, > workflow management, presentation logic, *and* content repositories. > The repository is only a (critical! important! vital!) piece of the CMS > puzzle, but it's foolish to consider a content repository enough to > implement a serious CMS. > This is true for the current stage of development but we hope to get this features in the future. We will port our process engine (for rendering and workflow management) to slide and are going to donate it to the slide project if the public likes it. So I think it should still remain under the flag of CMS. > I think it's vital, for the success of a project, not to fool around > with its own marketing. > > I would like to invite this community to discuss the "remarketing" of > slide and propose "retargetting" of the project. > > [note: this will also make it easier to market Slide as the reference > implementation of the JSR-170 in the future. FYI: I am the ASF > representative for JSR-170 in the expert group] > > > solidification > -- > > users that checkout the code for the first time, have a hard time > understanding what parts of the code are maintained and what are not. I > would like to propose a few things here: > > 1) clear separation of the server part from the client part. When you > download the slide CVS, you get server and client at the same time, > with the same build, docs and all that. I think we should clearly > separate those things out. Potentially, in the future, Slide could > become a "top level" ASF project (think slide.apache.org) and we might > further change into slide-server and slide-client as CVS modules. I > think separation will increase the ability for others to get in and > help. This makes sense as server and client part are independent. > > 2) separation of the life code from the dead one. For this, the > suggestion is the creation of a "/scratchpad" folder in the root of the > jakarta-slide CVS module and place all dead code there. Alternatively, > it's possible to use the existing "/proposal" folder. Candidates for > dead code consideration are: > >a) the unmaintained stores >b) the GUI for the webdav client > Oliver checked in the attic-directory to move some unmaintained code in. > > build process > - > > I think users should be able to do > > cvs co jakarta-slide > ant > ./slide > > and get it running. The required (non-optional) jars should be included > in the download or fetched by the build script from jar repositories > (the only problem seems to be JTA which is under the Sun license, so we > can't put it in CVS, but the Geronimo guys already reimplemented it > under the apache license, so we can use that). This is a big point if more people start building slide from cvs. Daniel > > what do you think? > > -- > Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
Stefano Mazzocchi wrote: ... > > 1) clear separation of the server part from the client part. > When you download the slide CVS, you get server and client at > the same time, > with the same build, docs and all that. I think we should > clearly separate those things out. Potentially, in the future, > Slide could become a "top level" ASF project (think > slide.apache.org) and we might further change into > slide-server and slide-client as CVS modules. I think > separation will increase the ability for others to get in and > help. > I would approve this proposal. The complexity of the whole CVS could discourage users who are interested in the client part. It is not easy to find the client library and examples. The build checks the same dependencies as the server build. But most of the libraries are not required for the client. The client is in a very usable state. This would be a great help for new users. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
On 14 Nov 2003, at 08:23, Oliver Zeigermann wrote: [COPIED FROM USERS LIST, THIS IS HERE IN THE DEV LIST IS THE RIGHT POST TO FOLLOW UP] Hi everyone! Hi! I understand those votes from active committers which are +1 from Martin +1 from Ingo +1 from Peter mean: 1. We actually should start a release process now that's great, but I think we should outline a list of showstoppers and decide what to do, see below for an attemp on that list. 2. I should be the release manager sounds good to me. Apache is a do-ocracy: who volunteers get the power (also the blame or the fame, whichever comes first ;-) If this is common understanding I'd like to start by discussing open issues in follow up posts. So, while others are welcome to start follow up threads, please restrict yourself to the topic of discussing this release in these follow ups. To the current status: I am optimistic I will get an acount and be granted commit access soon, as recent email communication with the PMC indicate this. As soon as this happens I will commit all my patches (only concerning stores, so do not worry and will also present the current status of the merged J2EE/JDBC store for public review. As soon as the store is more or less stable I will adapt both this one and the file store to the new ACL implementation (provided adaption is needed). I am too chicken-hearted to check the new ACL stuff out, before having fixed the store Yeah, one thing at the time. That's it for now, details in the follow ups. I think we need a little plan of action. (of course, since I'm not an active committer, I don't get to vote, but at least I'll share some of my experience in these things). new generation number - From a user perspective, Slide appeared dead for too long. Doing a release with a 2.0 number will give the impression that things are changing on this regard and it's a thing that people will like, even if the architecture hasn't changed. bad marketing - I believe Slide has currently a major bug in its own self-marketing: no matter how you look at it, Slide is *NOT* a content management system. Probably Remy (or Yassaf/Keith/Ismael don't know who came up with this) didn't know what a content management system was, but one thing is for sure: Slide is a content repository not a content management system. A CMS includes things like content authoring, content auditing, workflow management, presentation logic, *and* content repositories. The repository is only a (critical! important! vital!) piece of the CMS puzzle, but it's foolish to consider a content repository enough to implement a serious CMS. I think it's vital, for the success of a project, not to fool around with its own marketing. I would like to invite this community to discuss the "remarketing" of slide and propose "retargetting" of the project. [note: this will also make it easier to market Slide as the reference implementation of the JSR-170 in the future. FYI: I am the ASF representative for JSR-170 in the expert group] solidification -- users that checkout the code for the first time, have a hard time understanding what parts of the code are maintained and what are not. I would like to propose a few things here: 1) clear separation of the server part from the client part. When you download the slide CVS, you get server and client at the same time, with the same build, docs and all that. I think we should clearly separate those things out. Potentially, in the future, Slide could become a "top level" ASF project (think slide.apache.org) and we might further change into slide-server and slide-client as CVS modules. I think separation will increase the ability for others to get in and help. 2) separation of the life code from the dead one. For this, the suggestion is the creation of a "/scratchpad" folder in the root of the jakarta-slide CVS module and place all dead code there. Alternatively, it's possible to use the existing "/proposal" folder. Candidates for dead code consideration are: a) the unmaintained stores b) the GUI for the webdav client build process - I think users should be able to do cvs co jakarta-slide ant ./slide and get it running. The required (non-optional) jars should be included in the download or fetched by the build script from jar repositories (the only problem seems to be JTA which is under the Sun license, so we can't put it in CVS, but the Geronimo guys already reimplemented it under the apache license, so we can use that). what do you think? -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: DISCUSSION: Slide 2.0 release
On 13 Nov 2003, at 21:52, robert burrell donkin wrote: the dev list is usually considered the right place for discussions about releases. certainly, all VOTEs must take place on the dev list. any release will mean several VOTEs usually starting with a release plan and the election (often by lazy acclamation) of the release manager. so, it's probably best to invite anyone from the user list who's interested over to the dev (rather than vice-versa). agreed, this is in line with all the other apache communities that I have participated in as well. -- Stefano. smime.p7s Description: S/MIME cryptographic signature
Re: DISCUSSION: Slide 2.0 release
OK. Will do so! Thanks Robert, I need you all the help I can get :) Oliver robert burrell donkin wrote: the dev list is usually considered the right place for discussions about releases. certainly, all VOTEs must take place on the dev list. any release will mean several VOTEs usually starting with a release plan and the election (often by lazy acclamation) of the release manager. so, it's probably best to invite anyone from the user list who's interested over to the dev (rather than vice-versa). - robert On 13 Nov 2003, at 15:29, Oliver Zeigermann wrote: For everyone subscribed to the dev list only: Discussion about the new release has been started in the user list. Please keep the discussion in that list. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DISCUSSION: Slide 2.0 release
the dev list is usually considered the right place for discussions about releases. certainly, all VOTEs must take place on the dev list. any release will mean several VOTEs usually starting with a release plan and the election (often by lazy acclamation) of the release manager. so, it's probably best to invite anyone from the user list who's interested over to the dev (rather than vice-versa). - robert On 13 Nov 2003, at 15:29, Oliver Zeigermann wrote: For everyone subscribed to the dev list only: Discussion about the new release has been started in the user list. Please keep the discussion in that list. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
