AW: accessing slide on the server side

Hi Kolja, I've been facing similar problems when working on the Projector framework. The main problem is that you'll not get the full user/password information out of the user credentials that tomcat provides (for security reasons). My choice was to provide a login-box at portal level and not to

Re: max revision limit?

Hi, I was just wondering if you'd made any progress with this? I've come up against this problem again now we are using a database backed version of Slide again, and it would be great if a solution was in the pipeline. It's certainly a design flaw as it is, and I can no longer make the fields

synchronize filesystem against oracle store

I have a large content management system holding over 400k+ files in an oracle store. By my estimate it will take over 10 hours to publish the entire store over and over again so I would like to do an incremental publish. Does anyone have any idea how, or know if there are any tools available to

Re: synchronize filesystem against oracle store

We have multiple slide servers and we wrote a custom store to publish a JXTA advertisement of the changed content and the remote slide JXTA peer picks up the ad and gets the content. However there are sync tools that will work via webdav and they may prove more easily implemented. Ollie

Configuring a principal store

OK, I've coded my own Principal store based on code from JNDIPrincipalStore and am setting up a test configuration. I'm a little confused how to setup domain.xml. First, my store will only handle /users and /roles. Everything else will be handled by J2EEStore. So, do I setup two separate

RE: AW: accessing slide on the server side

Hi there! Your reply begs a question as to whether forms auth can be used with MS WebFolders, Adobe Acrobat, NetDrive and other commonly available DAV clients. Have you used forms auth with these clients before? I would assume the client would need a browser to be able to support forms

RE: AW: accessing slide on the server side

Hi Andrey, Excuse my ignorance, but in simple terms what is the protocol underlying digest auth? Does WebFolders actually implement the client piece of the authentication mechanism? I'm trying to understand how sophisticated a web client WebFolders is and whether it is actively participating in

Re: AW: accessing slide on the server side

Warwick Burrows wrote: Your reply begs a question as to whether forms auth can be used with MS WebFolders, Adobe Acrobat, NetDrive and other commonly available DAV clients. Have you used forms auth with these clients before? I would assume the client would need a browser to be able to support

Will OJB require db migration?

Carlos, will the new OBJ store implementation require that we migrate our Slide 2.1 databases (ouch!) or will the schema generated by OJB match the existing schema for our DBs? We will shortly release our current product on Slide 2.1 with many, many thousands of files. We plan to release our

RE: Will OJB require db migration?

Oops. I should have finished reading your email. The OJB changes will definitely require data migration then... What kind of changes are we talking about? Thanks. -Original Message- From: Warwick Burrows Sent: Thursday, February 10, 2005 8:03 PM To: Slide Users Mailing List

RE: AW: accessing slide on the server side

Hi, Warwick! Excuse my ignorance, but in simple terms what is the protocol underlying digest auth? Well, HTTP: http://www.ietf.org/rfc/rfc2617.txt Does WebFolders actually implement the client piece of the authentication mechanism? Yes, I suppose so. I'm trying to understand how

RE: AW: accessing slide on the server side

Thanks very much! -Original Message- From: Andrey Shulinsky [mailto:[EMAIL PROTECTED] Sent: Thursday, February 10, 2005 8:16 PM To: 'Slide Users Mailing List' Subject: RE: AW: accessing slide on the server side Hi, Warwick! Excuse my ignorance, but in simple terms what is

Re: Will OJB require db migration?

Well, one of the things is that OJB uses a common schema for all databases. Some of the currrent RDBMS stores use integer while others use long for the id fields. I chose long, but that shouldn't be much of a problem. I also changed the date fields to map to SQL TIMESTAMP type instead of long.

Re: Configuring a principal store

Your second example is correct. The securitystore is for controlling access to the nodes from that store. So in this case it would hold permissions for who is allowed to view information about your users (or roles). You can see an example config in CVS: