Re: Exceptions when I try to setup a mysql JDBC store
It seems you have not created the tables. This has to be done manually.
Unfortunately, those schemas are not included in the binary release, but
will be in release candidate 1. You can find the schemas here
http://cvs.apache.org/viewcvs.cgi/jakarta-slide/src/conf/schema/
and the one for MySQL
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-slide/src/conf/schema/MySqlSchema.sql?rev=1.1.2.1
Oliver
Ryan Rhodes wrote:
I am trying to setup a JDBC store for the first time using mysql. I
copied the domain.xml from a copy a found online, but I get Exceptions
when I start the server. It looks like it is failing to create the
initial tables in the database.
Can anyone help out with this problem?
Can anyone confirm for me that slide creates it's own tables and that I
don't need to create them manually?
Here is the domain.xml:
definition
store name=jdbc
nodestore classname=org.apache.slide.store.impl.rdbms.JDBCStore
parameter
name=adapterorg.apache.slide.store.impl.rdbms.MySqlRDBMSAdapter/parameter
parameter name=drivercom.mysql.jdbc.Driver/parameter
parameter
name=urljdbc:mysql://192.168.1.15/piefinger/parameter
parameter name=userauser/parameter
parameter name=passwordapassword/parameter
parameter name=dbcpPoolingtrue/parameter
parameter name=maxPooledConnections10/parameter
parameter name=isolationSERIALIZABLE/parameter
parameter name=compressfalse/parameter
/nodestore
securitystore
reference store=nodestore /
/securitystore
lockstore
reference store=nodestore /
/lockstore
revisiondescriptorsstore
reference store=nodestore /
/revisiondescriptorsstore
revisiondescriptorstore
reference store=nodestore /
/revisiondescriptorstore
contentstore
classname=org.apache.slide.store.txfile.TxFileContentStore
parameter name=rootpath/blarg_contentstore/parameter
parameter name=workpath/blarg_workingresource/parameter
parameter name=versionfalse/parameter
parameter name=resetBeforeStartingfalse/parameter
/contentstore
/store
scope match=/ store=jdbc /
/definition
Here is the server log:
29 Mar 2004 16:43:13 - org.apache.slide.common.Domain - INFO -
Initializing Domain
29 Mar 2004 16:43:13 - org.apache.slide.common.Domain - INFO - Domain
configuration : {org.apache.slide.lock=true,
org.apache.slide.versioncontrol=true, org.apache.slide.debug=false,
org.apache.slide.search=true, org.apache.slide.security=true,
org.apache.slide.domain=E:/tmp/Slide 2.0b1 Tomcat 5.0/slide/Domain.xml}
29 Mar 2004 16:43:13 - org.apache.slide.common.Domain - INFO - Domain
parameters: {logger-level=6, versioncontrol-exclude=,
auto-version=checkout-checkin, historypath=/history,
checkin-fork=forbidden, workingresourcepath=/workingresource,
workspacepath=/workspace, default=slide, auto-version-control=false,
logger=org.apache.slide.util.logger.SimpleLogger, checkout-fork=forbidden}
29 Mar 2004 16:43:13 - org.apache.slide.common.Domain - INFO -
Initializing namespace : slide
29 Mar 2004 16:43:13 - org.apache.slide.common.Namespace - INFO -
Loading namespace slide parameters
29 Mar 2004 16:43:14 - org.apache.slide.common.Namespace - INFO -
Loading namespace definition
29 Mar 2004 16:43:14 - org.apache.slide.common.Namespace - INFO - Node
store: org.apache.slide.store.impl.rdbms.JDBCStore
29 Mar 2004 16:43:14 - org.apache.slide.store.impl.rdbms.JDBCStore -
INFO - Loading and registering driver 'com.mysql.jdbc.Driver'
29 Mar 2004 16:43:14 - org.apache.slide.store.impl.rdbms.JDBCStore -
INFO - Setting isolation level 'SERIALIZABLE'
29 Mar 2004 16:43:14 - org.apache.slide.store.impl.rdbms.JDBCStore -
INFO - Using DBCP pooling
29 Mar 2004 16:43:14 - org.apache.slide.store.impl.rdbms.JDBCStore -
INFO - Number of connections set to 10
29 Mar 2004 16:43:14 - org.apache.slide.common.Namespace - INFO -
Security store references nodestore
29 Mar 2004 16:43:14 - org.apache.slide.common.Namespace - INFO - Lock
store store references nodestore
29 Mar 2004 16:43:14 - org.apache.slide.common.Namespace - INFO -
Revision descriptors store references nodestore
29 Mar 2004 16:43:14 - org.apache.slide.common.Namespace - INFO -
Revision descriptor store references nodestore
29 Mar 2004 16:43:14 - org.apache.slide.common.Namespace - INFO -
Content store: org.apache.slide.store.txfile.TxFileContentStore
29 Mar 2004 16:43:14 -
org.apache.slide.store.txfile.AbstractTxFileStoreService - INFO - File
Store configured to /blarg_contentstore, working directory
/blarg_workingresource
29 Mar 2004 16:43:14 - INFO - Setting object cache size for store jdbc
to 1
29 Mar 2004 16:43:14 - org.apache.slide.store.ExtendedStore - INFO -
Setting permission cache size for store jdbc to 1
29 Mar 2004 16:43:14 - org.apache.slide.store.ExtendedStore - INFO -
Setting lock cache size for store
RE: Slide 2 and Search in Binary Files
Hi, the correct way would be as follows: write an extractor, that extracts text data out of binary files (doc, pdf, ...) use an indexer, for example Lucene to index this stuff implement a contains query running on Lucene. Currently Christophe Lombart and Daniel Florey is working on that, I was on it as well, but currently I have no chance to spend time for slide. The current implementation for CONTAINS is quite slow, it really searches in all documents without using an index, so a Lucene based CONTAINS is very useful. Regards, Martin Wallmer -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Holz Sent: Dienstag, 30. März 2004 09:44 To: [EMAIL PROTECTED] Subject: Re: Slide 2 and Search in Binary Files Muhammad Asif [EMAIL PROTECTED] writes: thanks martin , i haven't jump into DASL yet but can i summarize it as currently slide treat binary files search as simple text. This is because when i opened word file in notepad and extracted a word from it and build a CONTAINS query it returns the search results successfully. Sorry, I should really look into the DASL stuff. - 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: Which API should I use for a web app?
Hi Daniel, This thread was of great interest to me, because very recently I experimented using Slide APIs directly from my Application. After reading this mail thread, I am considering using Slide's Client APIs instead of directly the server side APIs, though this would require me to code separately for distributed transaction management (My App specific DB operations + Slide operations -- in one atomic operation). Before making the final decision, I wanted to confirm whether I understood this correctly: BTW: Slide is (at the moment) far to slow to serve any webapp in real time. I'm currently working on a process engine that is doing all the caching and background-building of webpages so that a webapp can be build on top of slide. It will take some weeks until it is at a usable stage, but this might be a choice for webapps in the future. First of all: Why would Slide be used for building webpages? As I see it, Slide is Abstract Content Repository, which in turn could map to multiple physical Data Stores. In that sense, Slide is parallel to any other Data Store when viewed from an Application's perspective. And so the only difference is in the communication layer that an Application uses to communicate with any other Data Store and that with Slide. When you mention background-building of webpages... are you referring to the fact that Slide communicates over the WebDAV(HTTP extension) protocol and by that fact it would be required to return a webpage in response to any request? If yes, would that mean that the performance impact is due to the communication layer between a WebApp and Slide? In other words, the performance impact can be attributed to using Slide's Client APIs inside our WebApp. And that could be avoided if we access Slide APIs directly from inside our WebApp. Is this interpretation correct? I have diagrammatically represented the above scenario(Slide being accessed from a WebApplication). In this scenario do you see Slide being usable (basically will there be any performance issue)? My apologies if I misunderstood you. Regards, Ritu -Original Message- From: Daniel Florey [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 9:20 PM To: Slide Users Mailing List Subject: Re: Which API should I use for a web app? Hi Ryan, at the moment it is not recommended to use the slide api directly as you don't have access to many features that are hacked into the webdav layer. I don't know if versioning is working by using the slide api, there is some revision support but it is somehow mixed up with the webdav layer, so my advice would be not to use it. If you use slide api you are tied to the same vm so your webapp is not very scalable. The client library is a good way to access slide as the webdav-layer will not change soo much in future. WVCM is an abstraction layer on top of webdav, so it is little slower than webdav clientlib but it would be nice, if you would give it a try so that the jsr can get some feedback. Regards, Daniel BTW: Slide is (at the moment) far to slow to serve any webapp in real time. I'm currently working on a process engine that is doing all the caching and background-building of webpages so that a webapp can be build on top of slide. It will take some weeks until it is at a usable stage, but this might be a choice for webapps in the future. ryan wrote: I'm looking at the slide client library, the slide API, and the WVCM API, and I can't figure out which one I should use for a web application. Can someone explain what the difference in these API's is? Does the Slide API support versioning? Would the Slide API be much faster than the other two because of the network traffic? Which API will support external transactions in the future? Thanks, Ryan Rhodes - 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]
Simple Slide commands
I am currently looking at the SLIDE implementation, and the code, considering using it for content management, and would like to develop it further. One simple thing i can't get to work is to do a simple OPEN from the CommandLine WebDav Client. Not much doc here i guess. I try a simple open localhost/slide -- and the commandline breaks down with an exeption, faster than you can do a CTRL + C. Obviously i am doing something wrong here, so i would appreciate any ideas? Best Regards Tore _ Få alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Slide 2 and Search in Binary Files
Hi, the slide search needs some redesign to fullfill the requests like yours that come up quit often: Full text search capabilities of different doc-types and even more important: speed. The current generic search is doing quit well regarding the DASl-spec but is not fast enough with the default store impls to be usable for complex queries. As this is a complex task don't expect anything before slide 2.1 Regards, Daniel Muhammad Asif wrote: hi, i need some information regarding searching in binary files (pdf, doc etc) using slide 2. Does slide support searching from inside the binary files? Does we need to formulate the queries in some special manner for searching in binary files. CONTAINS doesn't seems to work with such files. Thanks. Asif - 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: Which API should I use for a web app?
Ritu Kedia wrote: Hi Daniel, This thread was of great interest to me, because very recently I experimented using Slide APIs directly from my Application. After reading this mail thread, I am considering using Slide's Client APIs instead of directly the server side APIs, though this would require me to code separately for distributed transaction management (My App specific DB operations + Slide operations -- in one atomic operation). Before making the final decision, I wanted to confirm whether I understood this correctly: BTW: Slide is (at the moment) far to slow to serve any webapp in real time. I'm currently working on a process engine that is doing all the caching and background-building of webpages so that a webapp can be build on top of slide. It will take some weeks until it is at a usable stage, but this might be a choice for webapps in the future. First of all: Why would Slide be used for building webpages? As I see it, Slide is Abstract Content Repository, which in turn could map to multiple physical Data Stores. In that sense, Slide is parallel to any other Data Store when viewed from an Application's perspective. And so the only difference is in the communication layer that an Application uses to communicate with any other Data Store and that with Slide. Yes, Slide is an abstract content repository but it depends on the kind of application you want to build on top of it, if it is really usable. What I was talking about was a portal like webapplication using some of the content displayed to the user by using slide. If you are thinking of a totally different app, the performance problems might not occur. Let's say you are thinking of a webapp that has several JSP-pages that work without retrieving data from slide while generating output and you have a download area where users can download documents it might be ok. But if you think of web pages that contain content that is stored in slide and will be retrieved while generating the page it will be really slow. The API you use will not make a very big difference as the performance problems occur inside the slide kernel (permission checking etc.) When you mention background-building of webpages... are you referring to the fact that Slide communicates over the WebDAV(HTTP extension) protocol and by that fact it would be required to return a webpage in response to any request? If yes, would that mean that the performance impact is due to the communication layer between a WebApp and Slide? In other words, the performance impact can be attributed to using Slide's Client APIs inside our WebApp. And that could be avoided if we access Slide APIs directly from inside our WebApp. Is this interpretation correct? No, the api makes no big difference. You should use the webdav lib or wvcm to access slide, otherwise your app is bound to the same vm. Regards, Daniel I have diagrammatically represented the above scenario(Slide being accessed from a WebApplication). In this scenario do you see Slide being usable (basically will there be any performance issue)? My apologies if I misunderstood you. Regards, Ritu -Original Message- From: Daniel Florey [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 9:20 PM To: Slide Users Mailing List Subject: Re: Which API should I use for a web app? Hi Ryan, at the moment it is not recommended to use the slide api directly as you don't have access to many features that are hacked into the webdav layer. I don't know if versioning is working by using the slide api, there is some revision support but it is somehow mixed up with the webdav layer, so my advice would be not to use it. If you use slide api you are tied to the same vm so your webapp is not very scalable. The client library is a good way to access slide as the webdav-layer will not change soo much in future. WVCM is an abstraction layer on top of webdav, so it is little slower than webdav clientlib but it would be nice, if you would give it a try so that the jsr can get some feedback. Regards, Daniel BTW: Slide is (at the moment) far to slow to serve any webapp in real time. I'm currently working on a process engine that is doing all the caching and background-building of webpages so that a webapp can be build on top of slide. It will take some weeks until it is at a usable stage, but this might be a choice for webapps in the future. ryan wrote: I'm looking at the slide client library, the slide API, and the WVCM API, and I can't figure out which one I should use for a web application. Can someone explain what the difference in these API's is? Does the Slide API support versioning? Would the Slide API be much faster than the other two because of the network traffic? Which API will support external transactions in the future? Thanks, Ryan Rhodes - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: Simple Slide commands
- Original Message - From: Tore Lading [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 27, 2004 1:21 PM Subject: Simple Slide commands I am currently looking at the SLIDE implementation, and the code, considering using it for content management, and would like to develop it further. One simple thing i can't get to work is to do a simple OPEN from the CommandLine WebDav Client. Not much doc here i guess. I try a simple open localhost/slide -- and the commandline breaks down with an exeption, faster than you can do a CTRL + C. connect http://localhost:8080/slide 8080 Tomcat port number Regards, -- Juan Andres Bentancour - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Which API should I use for a web app?
Hello Daniel, Thanks a lot for your reply. Please find my comments inline. -Original Message- From: Daniel Florey [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 3:08 PM To: Slide Users Mailing List Subject: Re: Which API should I use for a web app? Yes, Slide is an abstract content repository but it depends on the kind of application you want to build on top of it, if it is really usable. What I was talking about was a portal like webapplication using some of the content displayed to the user by using slide. If you are thinking of a totally different app, the performance problems might not occur. Let's say you are thinking of a webapp that has several JSP-pages that work without retrieving data from slide while generating output and you have a download area where users can download documents it might be ok. But if you think of web pages that contain content that is stored in slide and will be retrieved while generating the page it will be really slow. The API you use will not make a very big difference as the performance problems occur inside the slide kernel (permission checking etc.) If the performance impact occurs inside the Slide Kernel, then how would it be different when accessed via a Web-Client as opposed to a Desktop-Client? The only difference is: in case of a Web-Client I would use some JSP/XSP and in case of a Desktop-Client I would use some Web-Service. With both the JSP/XSP and Web-Services internally using the Slide Client LIB to access Slide's WebDAV Service. In your example above, when you say retrieving data from Slide, do you imply retrieving actual Content or retrieving any information: MetaData or Content? E.G. 1. if the client(Web/Desktop) wants to view all the sub-folders inside a folder, a Slide WebDAV ls command would be issued and the results would be wrapped in respective format and returned to the client. E.G. 2. if the client(Web/Desktop) wants to download all the files in a folder, a recursive Slide WebDAV Get command would be issued and the results would be wrapped in respective format and returned to the client. Will there be performance impact in both cases or only case 2 (large information download)? Sorry for going into so much details... But I really did not understand the difference between a Web-Client and a Desktop-Client. The security and lock checks would be required in both cases. And most likely both cases would be communicating with server over http. When you mention background-building of webpages... are you referring to the fact that Slide communicates over the WebDAV(HTTP extension) protocol and by that fact it would be required to return a webpage in response to any request? If yes, would that mean that the performance impact is due to the communication layer between a WebApp and Slide? In other words, the performance impact can be attributed to using Slide's Client APIs inside our WebApp. And that could be avoided if we access Slide APIs directly from inside our WebApp. Is this interpretation correct? No, the api makes no big difference. You should use the webdav lib or wvcm to access slide, otherwise your app is bound to the same vm. When using the Client LIB, wouldn't there be a big performance difference due to the additional HTTP communication layer introduced(I am referring to using Client LIB from inside a JSP or Web-Service on the Server side)? (Having the Slide APIs run in the same VM is acceptable). However I think not having a clean separation between the WebDAV and the Slide API layer would mandate the use of the Client or WVCM libraries. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which API should I use for a web app?
Ritu Kedia wrote: Hello Daniel, Thanks a lot for your reply. Please find my comments inline. -Original Message- From: Daniel Florey [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 3:08 PM To: Slide Users Mailing List Subject: Re: Which API should I use for a web app? Yes, Slide is an abstract content repository but it depends on the kind of application you want to build on top of it, if it is really usable. What I was talking about was a portal like webapplication using some of the content displayed to the user by using slide. If you are thinking of a totally different app, the performance problems might not occur. Let's say you are thinking of a webapp that has several JSP-pages that work without retrieving data from slide while generating output and you have a download area where users can download documents it might be ok. But if you think of web pages that contain content that is stored in slide and will be retrieved while generating the page it will be really slow. The API you use will not make a very big difference as the performance problems occur inside the slide kernel (permission checking etc.) If the performance impact occurs inside the Slide Kernel, then how would it be different when accessed via a Web-Client as opposed to a Desktop-Client? The only difference is: in case of a Web-Client I would use some JSP/XSP and in case of a Desktop-Client I would use some Web-Service. With both the JSP/XSP and Web-Services internally using the Slide Client LIB to access Slide's WebDAV Service. In your example above, when you say retrieving data from Slide, do you imply retrieving actual Content or retrieving any information: MetaData or Content? E.G. 1. if the client(Web/Desktop) wants to view all the sub-folders inside a folder, a Slide WebDAV ls command would be issued and the results would be wrapped in respective format and returned to the client. E.G. 2. if the client(Web/Desktop) wants to download all the files in a folder, a recursive Slide WebDAV Get command would be issued and the results would be wrapped in respective format and returned to the client. Will there be performance impact in both cases or only case 2 (large information download)? Sorry for going into so much details... But I really did not understand the difference between a Web-Client and a Desktop-Client. The security and lock checks would be required in both cases. And most likely both cases would be communicating with server over http. When you mention background-building of webpages... are you referring to the fact that Slide communicates over the WebDAV(HTTP extension) protocol and by that fact it would be required to return a webpage in response to any request? If yes, would that mean that the performance impact is due to the communication layer between a WebApp and Slide? In other words, the performance impact can be attributed to using Slide's Client APIs inside our WebApp. And that could be avoided if we access Slide APIs directly from inside our WebApp. Is this interpretation correct? No, the api makes no big difference. You should use the webdav lib or wvcm to access slide, otherwise your app is bound to the same vm. When using the Client LIB, wouldn't there be a big performance difference due to the additional HTTP communication layer introduced(I am referring to using Client LIB from inside a JSP or Web-Service on the Server side)? (Having the Slide APIs run in the same VM is acceptable). However I think not having a clean separation between the WebDAV and the Slide API layer would mandate the use of the Client or WVCM libraries. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . Hi, there is no performance difference in using slide from webapp or desktop-client view. But normally it is more acceptable if you e.g. want to save a word document to slide or load it and wait a few seconds for it. Or if you open a folder in webfolder view it is acceptable if it takes another several seconds. But if you want to build a webapp the user in not used to wait several seconds for a page. And also there are much more parrallel users using a webapp than document editors. So if you want to build a dynamic webapp based on slide stored content, it will be damned slow if you don't cache the rendered pages until content is changed. I've integrated the event based stuff to enable some webapp like this. But it depends on the needs of your application. The protocol layer will for sure add some overhead, but this is not the big point. As the slide API will probably change in future releases it would be my strong advice to use the webdav api instead. Regards, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED]
RE: Which API should I use for a web app?
Daniel thanks really for all your feedback. Just one last question: If I decide to use the Slide APIs directly and turn off Slide's Security Checks using SlideTokenWrapper SlideToken token = new SlideTokenImpl(credentials); token.setEnforceLockTokens(true); SlideToken tokenWrapper = new SlideTokenWrapper(token,true); tokenWrapper.setForceSecurity(false); And provide my own LockStore, since I will be maintaining user list in my own Schema. Will this configuration significantly reduce the performance bottleneck? Basically, is security check the main performance impairer? Regards and Thanks, Ritu -Original Message- From: Daniel Florey [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 5:15 PM To: Slide Users Mailing List Subject: Re: Which API should I use for a web app? Ritu Kedia wrote: Hello Daniel, Thanks a lot for your reply. Please find my comments inline. -Original Message- From: Daniel Florey [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 3:08 PM To: Slide Users Mailing List Subject: Re: Which API should I use for a web app? Yes, Slide is an abstract content repository but it depends on the kind of application you want to build on top of it, if it is really usable. What I was talking about was a portal like webapplication using some of the content displayed to the user by using slide. If you are thinking of a totally different app, the performance problems might not occur. Let's say you are thinking of a webapp that has several JSP-pages that work without retrieving data from slide while generating output and you have a download area where users can download documents it might be ok. But if you think of web pages that contain content that is stored in slide and will be retrieved while generating the page it will be really slow. The API you use will not make a very big difference as the performance problems occur inside the slide kernel (permission checking etc.) If the performance impact occurs inside the Slide Kernel, then how would it be different when accessed via a Web-Client as opposed to a Desktop-Client? The only difference is: in case of a Web-Client I would use some JSP/XSP and in case of a Desktop-Client I would use some Web-Service. With both the JSP/XSP and Web-Services internally using the Slide Client LIB to access Slide's WebDAV Service. In your example above, when you say retrieving data from Slide, do you imply retrieving actual Content or retrieving any information: MetaData or Content? E.G. 1. if the client(Web/Desktop) wants to view all the sub-folders inside a folder, a Slide WebDAV ls command would be issued and the results would be wrapped in respective format and returned to the client. E.G. 2. if the client(Web/Desktop) wants to download all the files in a folder, a recursive Slide WebDAV Get command would be issued and the results would be wrapped in respective format and returned to the client. Will there be performance impact in both cases or only case 2 (large information download)? Sorry for going into so much details... But I really did not understand the difference between a Web-Client and a Desktop-Client. The security and lock checks would be required in both cases. And most likely both cases would be communicating with server over http. When you mention background-building of webpages... are you referring to the fact that Slide communicates over the WebDAV(HTTP extension) protocol and by that fact it would be required to return a webpage in response to any request? If yes, would that mean that the performance impact is due to the communication layer between a WebApp and Slide? In other words, the performance impact can be attributed to using Slide's Client APIs inside our WebApp. And that could be avoided if we access Slide APIs directly from inside our WebApp. Is this interpretation correct? No, the api makes no big difference. You should use the webdav lib or wvcm to access slide, otherwise your app is bound to the same vm. When using the Client LIB, wouldn't there be a big performance difference due to the additional HTTP communication layer introduced(I am referring to using Client LIB from inside a JSP or Web-Service on the Server side)? (Having the Slide APIs run in the same VM is acceptable). However I think not having a clean separation between the WebDAV and the Slide API layer would mandate the use of the Client or WVCM libraries. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . Hi, there is no performance
Re: Which API should I use for a web app?
Ritu Kedia wrote: Daniel thanks really for all your feedback. Just one last question: If I decide to use the Slide APIs directly and turn off Slide's Security Checks using SlideTokenWrapper SlideToken token = new SlideTokenImpl(credentials); token.setEnforceLockTokens(true); SlideToken tokenWrapper = new SlideTokenWrapper(token,true); tokenWrapper.setForceSecurity(false); And provide my own LockStore, since I will be maintaining user list in my own Schema. Will this configuration significantly reduce the performance bottleneck? Basically, is security check the main performance impairer? I think it will at least not be worse ;-) And I'd appreciate any further information on the performance issue. If you use the slide API for storing data from your app, take into account that it is reallly complicated to store content in a way that you can use the versioning stuff, because all of the versioning is done in the webdav layer. For fast content retrieval in the same vm, slide API might be a good choice. Regards, Daniel Regards and Thanks, Ritu -Original Message- From: Daniel Florey [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 5:15 PM To: Slide Users Mailing List Subject: Re: Which API should I use for a web app? Ritu Kedia wrote: Hello Daniel, Thanks a lot for your reply. Please find my comments inline. -Original Message- From: Daniel Florey [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 3:08 PM To: Slide Users Mailing List Subject: Re: Which API should I use for a web app? Yes, Slide is an abstract content repository but it depends on the kind of application you want to build on top of it, if it is really usable. What I was talking about was a portal like webapplication using some of the content displayed to the user by using slide. If you are thinking of a totally different app, the performance problems might not occur. Let's say you are thinking of a webapp that has several JSP-pages that work without retrieving data from slide while generating output and you have a download area where users can download documents it might be ok. But if you think of web pages that contain content that is stored in slide and will be retrieved while generating the page it will be really slow. The API you use will not make a very big difference as the performance problems occur inside the slide kernel (permission checking etc.) If the performance impact occurs inside the Slide Kernel, then how would it be different when accessed via a Web-Client as opposed to a Desktop-Client? The only difference is: in case of a Web-Client I would use some JSP/XSP and in case of a Desktop-Client I would use some Web-Service. With both the JSP/XSP and Web-Services internally using the Slide Client LIB to access Slide's WebDAV Service. In your example above, when you say retrieving data from Slide, do you imply retrieving actual Content or retrieving any information: MetaData or Content? E.G. 1. if the client(Web/Desktop) wants to view all the sub-folders inside a folder, a Slide WebDAV ls command would be issued and the results would be wrapped in respective format and returned to the client. E.G. 2. if the client(Web/Desktop) wants to download all the files in a folder, a recursive Slide WebDAV Get command would be issued and the results would be wrapped in respective format and returned to the client. Will there be performance impact in both cases or only case 2 (large information download)? Sorry for going into so much details... But I really did not understand the difference between a Web-Client and a Desktop-Client. The security and lock checks would be required in both cases. And most likely both cases would be communicating with server over http. When you mention background-building of webpages... are you referring to the fact that Slide communicates over the WebDAV(HTTP extension) protocol and by that fact it would be required to return a webpage in response to any request? If yes, would that mean that the performance impact is due to the communication layer between a WebApp and Slide? In other words, the performance impact can be attributed to using Slide's Client APIs inside our WebApp. And that could be avoided if we access Slide APIs directly from inside our WebApp. Is this interpretation correct? No, the api makes no big difference. You should use the webdav lib or wvcm to access slide, otherwise your app is bound to the same vm. When
Free + java-based HTTP Sniffer recommendation ??
Hi, can somebody recommend a free + java-based HTTP Sniffer? Currently I'm using NetTool from Neil O'Toole [http://www.nettool.org] ... which isn't bad ... but I'd like to see some alternatives. TIA and regards, Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Free + java-based HTTP Sniffer recommendation ??
I am using the same tool and agree with Peter in all respects. Oliver [EMAIL PROTECTED] wrote: Hi, can somebody recommend a free + java-based HTTP Sniffer? Currently I'm using NetTool from Neil O'Toole [http://www.nettool.org] ... which isn't bad ... but I'd like to see some alternatives. TIA and regards, Peter - 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: Free + java-based HTTP Sniffer recommendation ??
[EMAIL PROTECTED] wrote: Hi, can somebody recommend a free + java-based HTTP Sniffer? Currently I'm using NetTool from Neil O'Toole [http://www.nettool.org] ... which isn't bad ... but I'd like to see some alternatives. TIA and regards, Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] in Apache SOAP v2.3.1 Documentation, they have a sniffer... Stan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Simple Slide commands
The argument to open includes the protocol so: Open http://localhost:8080/slide __ Michael Oliver CTO Matrix Intermedia Inc 7391 S. Bullrider Ave. Tucson, AZ 85747 Phone +1 (520) 574-1150 Fax +1 (520) 844-1036 ICQ#: 318986322 Current ICQ status: * More ways to contact me __ -Original Message- From: Tore Lading [mailto:[EMAIL PROTECTED] Sent: Saturday, March 27, 2004 9:22 AM To: [EMAIL PROTECTED] Subject: Simple Slide commands I am currently looking at the SLIDE implementation, and the code, considering using it for content management, and would like to develop it further. One simple thing i can't get to work is to do a simple OPEN from the CommandLine WebDav Client. Not much doc here i guess. I try a simple open localhost/slide -- and the commandline breaks down with an exeption, faster than you can do a CTRL + C. Obviously i am doing something wrong here, so i would appreciate any ideas? Best Regards Tore _ Få alle de nye og sjove ikoner med MSN Messenger http://messenger.msn.dk/ - 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: Which API should I use for a web app?
If you use the slide API for storing data from your app, take into account that it is reallly complicated to store content in a way that you can use the versioning stuff, because all of the versioning is done in the webdav layer. What do you mean ? The slide API can manage NodeRevisionDescriptors and NodeRevisionDescriptor. It is not what you expect to do ? or are you speaking about other features ? For fast content retrieval in the same vm, slide API might be a good choice. I'm using the Slide API from a Jetspeed service and its works fine. We have -/+ 20.000 documents and no problem at all. Maybe, if we have more and more documents, this solution will not be scalable. So, next plan is to access to different external repositories via the webdav client. Christophe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which API should I use for a web app?
[EMAIL PROTECTED] wrote: If you use the slide API for storing data from your app, take into account that it is reallly complicated to store content in a way that you can use the versioning stuff, because all of the versioning is done in the webdav layer. What do you mean ? The slide API can manage NodeRevisionDescriptors and NodeRevisionDescriptor. It is not what you expect to do ? or are you speaking about other features ? It would make me happy if you're right. I have not checked it yet, but from the parts of the code that I've seen I can't imagine that you can access revisions via deltaV if you create them by simply adding new revisions via slide api. Can you? Regards, Daniel For fast content retrieval in the same vm, slide API might be a good choice. I'm using the Slide API from a Jetspeed service and its works fine. We have -/+ 20.000 documents and no problem at all. Maybe, if we have more and more documents, this solution will not be scalable. So, next plan is to access to different external repositories via the webdav client. Christophe - 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: Free + java-based HTTP Sniffer recommendation ??
Stan Pinte wrote: [EMAIL PROTECTED] wrote: Hi, can somebody recommend a free + java-based HTTP Sniffer? Currently I'm using NetTool from Neil O'Toole [http://www.nettool.org] ... which isn't bad ... but I'd like to see some alternatives. in Apache SOAP v2.3.1 Documentation, they have a sniffer... Apache Axis comes with a nice one (tcpmon) as well. Guido - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Free + java-based HTTP Sniffer recommendation ??
I use this: http://httptrace.sourceforge.net/ Martin [EMAIL PROTECTED] wrote: Hi, can somebody recommend a free + java-based HTTP Sniffer? Currently I'm using NetTool from Neil O'Toole [http://www.nettool.org] ... which isn't bad ... but I'd like to see some alternatives. TIA and regards, Peter - 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: Which API should I use for a web app?
It would make me happy if you're right. I have not checked it yet, but from the parts of the code that I've seen I can't imagine that you can access revisions via deltaV if you create them by simply adding new revisions via slide api. Can you? Well, I'm not yet using the Webdav layer. Everything is done via the Slide API. Later, we plan to use Webdav. So, I don't know. Anyway, I can create from the Slide API a new RevisionDescriptor and retrieve all info about the current RevisionDescriptors as well. I'm writting a getting starting with the Slide API for my team. If needed, I can post a first draft for thoses who are interesting. Christophe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Which API should I use for a web app?
[EMAIL PROTECTED] writes: It would make me happy if you're right. I have not checked it yet, but from the parts of the code that I've seen I can't imagine that you can access revisions via deltaV if you create them by simply adding new revisions via slide api. Can you? Well, I'm not yet using the Webdav layer. Everything is done via the Slide API. Later, we plan to use Webdav. So, I don't know. Anyway, I can create from the Slide API a new RevisionDescriptor and retrieve all info about the current RevisionDescriptors as well. I'm writting a getting starting with the Slide API for my team. If needed, I can post a first draft for thoses who are interesting. You can use slide API versioning, but it is different from webdav API versioning. The webdav layer uses the slide versioning internally, but does a URI remapping and adds a lot of extra properties. Switching from one layer to the other is not trivial. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Which API should I use for a web app?
You can use slide API versioning, but it is different from webdav API versioning. The webdav layer uses the slide versioning internally, but does a URI remapping and adds a lot of extra properties. Switching from one layer to the other is not trivial. OK, Thanks, now I understand what is the difference between the Slide API and the webdav layer in point of view versionning! Christophe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat Realm/tomcat-users still open question
Well the last question didn't get a response so I will rephrase. Given we want to use the default Tomcat Realm UserDatabase aka tomcat-users.xml for authentication because we have other webapps than Slide that we want to run on that Tomcat. We thought (gleaned from the mailist) that we could add users by adding them to Tomcat and assigning the user role to that user and then creating a collection under /slide/users/ for each new user with a mkcol newuser. But that doesn't appear to work by itself. Even though we know that the Domain.xml data element is only used during initialization of the slide stores (Tx*) we added the user there as well as in the member set for the /slide/roles/user element. We Still don't see that user being able to do a put in a collection where the acls show /roles/user having write permission. We cannot find instructions on adding Slide users when using the Default tomcat-users.xml UserDatabase. Is there anything different than what we have done? Michael Oliver CTO Matrix Intermedia Inc. 7391 S. Bullrider Ave. Tucson, AZ 85747 Phone:(520)574-1150 Fax:(520)844-1036
getting started using slide
hi, all I am a new slide user. I have installed = slide1.0.16=20 bundled with Tomcat 4.0.1. After I startup the Slide(using the startup = command),=20 it shows following in the command window: Set domain for Slide host Set domain = for Webdav=20 host Set domain for Slide admin host Starting Slide Slide=20 started Starting service Slide Tomcat Apache = Tomcat/4.0.1 Starting=20 service Slide WebDAV Apache Tomcat/4.0.1 Starting service Slide=20 Admin Apache Tomcat/4.0.1 href=3Dhttp://localhost:8080/slide;http://localhost:8080/slide. = what's the=20 problem? Cheers. _ MSN Messenger: http://messenger.msn.com/cn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: getting started using slide
You should be using the release candidate, 1.0.16 is very old and you will be happier with the latest. __ Michael Oliver CTO Matrix Intermedia Inc 7391 S. Bullrider Ave. Tucson, AZ 85747 Phone +1 (520) 574-1150 Fax +1 (520) 844-1036 ICQ#: 318986322 Current ICQ status: * More ways to contact me __ -Original Message- From: [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 8:15 AM To: [EMAIL PROTECTED] Subject: getting started using slide hi, all I am a new slide user. I have installed = slide1.0.16=20 bundled with Tomcat 4.0.1. After I startup the Slide(using the startup = command),=20 it shows following in the command window: Set domain for Slide host Set domain = for Webdav=20 host Set domain for Slide admin host Starting Slide Slide=20 started Starting service Slide Tomcat Apache = Tomcat/4.0.1 Starting=20 service Slide WebDAV Apache Tomcat/4.0.1 Starting service Slide=20 Admin Apache Tomcat/4.0.1 href=3Dhttp://localhost:8080/slide;http://localhost:8080/slide. = what's the=20 problem? Cheers. _ MSN Messenger: http://messenger.msn.com/cn - 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]
J2EE Store vs. JDBC Store
Is the only difference in the J2EE store and the JDBC store that I can configure the connection for the J2EE store at the application server level? The higher level features like connection pooling... etc.. don't affect slide... or do they? _ Check out MSN PC Safety Security to help ensure your PC is protected and safe. http://specials.msn.com/msn/security.asp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getting started using slide
Michael Oliver wrote: You should be using the release candidate, 1.0.16 is very old and you will be happier with the latest. by the way, I have got a client prototype, on which there is a lot of data, using a CVS from august 2003. I am now using slide-2.0b1. (much better), but is there a way to migrate the content from this config: JDBCDescriptorStore/FileContentStore to the following: TxXMLFileDescriptorsStore/TxFileContentStore ??? I have got much data into these, and the content is versionned... thanks a lot, Stan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: J2EE Store vs. JDBC Store
Ryan Rhodes [EMAIL PROTECTED] writes: Is the only difference in the J2EE store and the JDBC store that I can configure the connection for the J2EE store at the application server level? Right (if you are talking about slide 2.0, in slide 1.x was a difference). The real work is done in the Adapters, which are shared by both stores. You can configure the JDBC store to use connection pooling too. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getting started using slide
Stan Pinte [EMAIL PROTECTED] writes: Michael Oliver wrote: You should be using the release candidate, 1.0.16 is very old and you will be happier with the latest. by the way, I have got a client prototype, on which there is a lot of data, using a CVS from august 2003. I am now using slide-2.0b1. (much better), but is there a way to migrate the content from this config: JDBCDescriptorStore/FileContentStore to the following: TxXMLFileDescriptorsStore/TxFileContentStore ??? I have got much data into these, and the content is versionned... No tool to migrate from JDBCDescriptorStore to TxXMLFileDescriptorsStore. I planed to write one but never found the spare time :-( I used the same setup and migrated to JDBCStore/OldJDBCAdapter + TxXMLFileDescriptorsStore. Much more reliable than the old stuff. You would probably have to overwrite the createException(SQLException e, Uri uri) method for your database and slightly modify your schema. And please do some tests before migrating your data. AFAIK there is no conversion necessary for TxFileContentStore except creating a work directory. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getting started using slide
No tool to migrate from JDBCDescriptorStore to TxXMLFileDescriptorsStore. I planed to write one but never found the spare time :-( I used the same setup and migrated to JDBCStore/OldJDBCAdapter + TxXMLFileDescriptorsStore. Much more reliable than the old stuff. You would probably have to overwrite the createException(SQLException e, Uri uri) method for your database and slightly modify your schema. And please do some tests before migrating your data. AFAIK there is no conversion necessary for TxFileContentStore except creating a work directory. and can't slide recreate the missing descriptors, in an empty descriptor DB? thanks a lot, Stan. 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: getting started using slide
If it were me, I would write a crawler that walked the tree of your old slide and copied the contents to the new slide via the Client Library, so much has changed under the covers I wouldn't begin to know where to start. This way your old slide works and the new slide works as is and you just have the crawler doing WebDAV gets and puts. __ Michael Oliver CTO Matrix Intermedia Inc 7391 S. Bullrider Ave. Tucson, AZ 85747 Phone +1 (520) 574-1150 Fax +1 (520) 844-1036 ICQ#: 318986322 Current ICQ status: * More ways to contact me __ -Original Message- From: Stan Pinte [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 8:36 AM To: Slide Users Mailing List Subject: Re: getting started using slide Michael Oliver wrote: You should be using the release candidate, 1.0.16 is very old and you will be happier with the latest. by the way, I have got a client prototype, on which there is a lot of data, using a CVS from august 2003. I am now using slide-2.0b1. (much better), but is there a way to migrate the content from this config: JDBCDescriptorStore/FileContentStore to the following: TxXMLFileDescriptorsStore/TxFileContentStore ??? I have got much data into these, and the content is versionned... thanks a lot, Stan. - 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: getting started using slide
Michael Oliver wrote: If it were me, I would write a crawler that walked the tree of your old slide and copied the contents to the new slide via the Client Library, so much has changed under the covers I wouldn't begin to know where to start. This way your old slide works and the new slide works as is and you just have the crawler doing WebDAV gets and puts. I'll do this, thanks!! Stan. __ Michael Oliver CTO Matrix Intermedia Inc 7391 S. Bullrider Ave. Tucson, AZ 85747 Phone +1 (520) 574-1150 Fax +1 (520) 844-1036 ICQ#: 318986322 Current ICQ status: * More ways to contact me __ -Original Message- From: Stan Pinte [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 8:36 AM To: Slide Users Mailing List Subject: Re: getting started using slide Michael Oliver wrote: You should be using the release candidate, 1.0.16 is very old and you will be happier with the latest. by the way, I have got a client prototype, on which there is a lot of data, using a CVS from august 2003. I am now using slide-2.0b1. (much better), but is there a way to migrate the content from this config: JDBCDescriptorStore/FileContentStore to the following: TxXMLFileDescriptorsStore/TxFileContentStore ??? I have got much data into these, and the content is versionned... thanks a lot, Stan. - 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: getting started using slide
Michael Oliver [EMAIL PROTECTED] writes: If it were me, I would write a crawler that walked the tree of your old slide and copied the contents to the new slide via the Client Library, so much has changed under the covers I wouldn't begin to know where to start. This way your old slide works and the new slide works as is and you just have the crawler doing WebDAV gets and puts. This would not work for version data and live properties. You could write a crawler, which uses the slide server API. Such a tool is really missing in slide. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getting started using slide
Martin Holz wrote: Michael Oliver [EMAIL PROTECTED] writes: If it were me, I would write a crawler that walked the tree of your old slide and copied the contents to the new slide via the Client Library, so much has changed under the covers I wouldn't begin to know where to start. This way your old slide works and the new slide works as is and you just have the crawler doing WebDAV gets and puts. This would not work for version data and live properties. You could write a crawler, which uses the slide server API. Such a tool is really missing in slide. can't I write a tool that first queries all versions of the doc, then get them, and then reproduce the version tree on the target DAV server? Stan. 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: getting started using slide
Stan Pinte [EMAIL PROTECTED] writes: Martin Holz wrote: Michael Oliver [EMAIL PROTECTED] writes: If it were me, I would write a crawler that walked the tree of your old slide and copied the contents to the new slide via the Client Library, so much has changed under the covers I wouldn't begin to know where to start. This way your old slide works and the new slide works as is and you just have the crawler doing WebDAV gets and puts. This would not work for version data and live properties. You could write a crawler, which uses the slide server API. Such a tool is really missing in slide. can't I write a tool that first queries all versions of the doc, then get them, and then reproduce the version tree on the target DAV server? Probably you could. But I think you would loose the date information and the author information too. Knowing who changed what when might be very important in some scenarios. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: getting started using slide
Yes that's the approach and since it is your data you would be able to tailor the tool to your properties as well. __ Michael Oliver CTO Matrix Intermedia Inc 7391 S. Bullrider Ave. Tucson, AZ 85747 Phone +1 (520) 574-1150 Fax +1 (520) 844-1036 ICQ#: 318986322 Current ICQ status: * More ways to contact me __ -Original Message- From: Stan Pinte [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 30, 2004 9:59 AM To: Slide Users Mailing List Subject: Re: getting started using slide Martin Holz wrote: Michael Oliver [EMAIL PROTECTED] writes: If it were me, I would write a crawler that walked the tree of your old slide and copied the contents to the new slide via the Client Library, so much has changed under the covers I wouldn't begin to know where to start. This way your old slide works and the new slide works as is and you just have the crawler doing WebDAV gets and puts. This would not work for version data and live properties. You could write a crawler, which uses the slide server API. Such a tool is really missing in slide. can't I write a tool that first queries all versions of the doc, then get them, and then reproduce the version tree on the target DAV server? Stan. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Which API should I use for a web app?
On 30 Mar 2004 at 16:26, [EMAIL PROTECTED] wrote: If you use the slide API for storing data from your app, take into account that it is reallly complicated to store content in a way that you can use the versioning stuff, because all of the versioning is done in the webdav layer. What do you mean ? The slide API can manage NodeRevisionDescriptors and NodeRevisionDescriptor. It is not what you expect to do ? or are you speaking about other features ? For fast content retrieval in the same vm, slide API might be a good choice. I'm using the Slide API from a Jetspeed service and its works fine. We have -/+ 20.000 documents and no problem at all. Maybe, if we have more and more documents, this solution will not be scalable. So, next plan is to access to different external repositories via the webdav client. Hi Christophe, there are major performance issues in the Slide kernel and database layer. 1. A collection SubjectNode always knows about all its children. With increasing collections the time to retrieve a collection SubjectNode will increase. Apart from this all children SubjectNodes are instanced to prepare the binding information. Solution would be to load the information about the children only on demand. To do this, the SubjectNode needs a pointer to the right NodeStore, which in turn needs some new methods. I implemented this with sub-classing the SubjectNode, which had been made more complicated than necessary with some private members and methods in ObjectNode :-( Of course some WebDAV methods need adaption to use the custom SubjectNode. 2. When adding a new child to a collection resource, all the old child entries of the collection resource are deleted, just to be saved again afterwards together with the information about the new child. The same is true for removing children. Solution would be to enhance the NodeStore interface with methods such as addChild and removeChild or so. Of course StructureImpl needs to be adapted too. Having done these two enhancements, I can tell you the performance has increased dramatically, especially when talking about many documents (1000). Nevertheless, the old database schema with slow datatypes (CLOB), which I had to use when doing the changes, prevents the usage of Slide with really many documents: On a server with 150,000 documents (70,000 in one collection) a put of a new document still needs a few seconds -- and unfortunately is rising with every new document. Maybe the new database schema is much better in this regard, but the two problems above remain. Regards, Andreas Christophe - 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: Slide 2 and Search in Binary Files
[EMAIL PROTECTED] wrote: Hi, the correct way would be as follows: write an extractor, that extracts text data out of binary files (doc, pdf, ...) use an indexer, for example Lucene to index this stuff implement a contains query running on Lucene. Currently Christophe Lombart and Daniel Florey is working on that, I was on it as well, but currently I have no chance to spend time for slide. This kind of extractor is not yet build but I sent 2 weeks ago a Lucene Indexer based on what Daniel made for the event management. Currently it can be used for simple situation (text/xml). Later, we can add more eleborate indexing mecanism. I don't know if one of Slide committers has time to check what I did. Furthermore I sent also a small bug fix for the IndexTrigger. Regards, Christophe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Free + java-based HTTP Sniffer recommendation ??
Martin Dulisch wrote: I use this: http://httptrace.sourceforge.net/ http://www.zaval.org/products/proxy/index.html Emile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
