Locking in Word

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Locking in Word

Jason Bradfield
Hi,

We are currently building a WebDav interface into our web based products document library.
Inside our product we allow users to lock and download documents. We are introducing WebDav to allow the users to open in Word and edit.

I have some questions regarding the behaviour we have seen. Although our implementation has just started so we may not be implementing the correct methods properly.
We are using the Resource interfaces as this fits better with our solution as we are not allowing users to mount using a filesystem, so we are not supporting any collection resources.

We have found that it does not matter if we open the document via ms-word:ofv|u|http://doc or ms-word:ofe|u|http://doc the experience is still the same.

See below for a sequence of calls from Word that we are seeing.

We propagate lock requests back to our database, where we are storing lock information.

My question is why is word trying to Lock and unlock the resource around an initial GET. Is there something we can do to prevent this. This will create a lot of noise in our database for people who just want to view the document. 


Open document
OPTIONS :: /document-webdav/72/
HEAD :: /document-webdav/72/-297102195.docx
OPTIONS :: /document-webdav/72/
LOCK :: /document-webdav/72/-297102195.docx
GET :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx
UNLOCK :: /document-webdav/72/-297102195.docx


Clicking Edit in Word
LOCK :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx


Saving... Uses previous lock token
LOCK :: /document-webdav/72/-297102195.docx
PUT :: /document-webdav/72/-297102195.docx

Closing Doc passing previous token
UNLOCK :: /document-webdav/72/-297102195.docx



Sample headers on the first lock request to give client details

headers
"user-agent" : "Microsoft Office Word 2014 (16.0.7030) Windows NT 10.0", "x-office-major-version" : "16", "x-ms-cookieuri-requested" : "t", "x-featureversion" : "1", "x-msgetweburl" : "t", "x-idcrl_accepted" : "t", "accept-encoding" : "gzip", "transfer-encoding" : "chunked", "host" : "localhost:9008", "connection" : "Keep-Alive”

We are authenticating users using MS-OFBA.

Thank you,
Jason




_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users
Reply | Threaded
Open this post in threaded view
|

Re: Locking in Word

bradmacnz

Hi Jason,

Firstly, you do not need to use the Resource API in your situation. The annotations framework is equivalent to the Resource API. Simply use @ChildOf instead of @ChildrenOf

Word will attempt to lock the resource in order to open it for editing. The only way to prevent this would be to give the user a choice in your web application, and if they just want to view then to open a resource which does not support lock and other write methods.

/Brad


On 17/08/16 17:51, Jason Bradfield wrote:
Hi,

We are currently building a WebDav interface into our web based products document library.
Inside our product we allow users to lock and download documents. We are introducing WebDav to allow the users to open in Word and edit.

I have some questions regarding the behaviour we have seen. Although our implementation has just started so we may not be implementing the correct methods properly.
We are using the Resource interfaces as this fits better with our solution as we are not allowing users to mount using a filesystem, so we are not supporting any collection resources.

We have found that it does not matter if we open the document via ms-word:ofv|u|http://doc or ms-word:ofe|u|http://doc the experience is still the same.

See below for a sequence of calls from Word that we are seeing.

We propagate lock requests back to our database, where we are storing lock information.

My question is why is word trying to Lock and unlock the resource around an initial GET. Is there something we can do to prevent this. This will create a lot of noise in our database for people who just want to view the document. 


Open document
OPTIONS :: /document-webdav/72/
HEAD :: /document-webdav/72/-297102195.docx
OPTIONS :: /document-webdav/72/
LOCK :: /document-webdav/72/-297102195.docx
GET :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx
UNLOCK :: /document-webdav/72/-297102195.docx


Clicking Edit in Word
LOCK :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx


Saving... Uses previous lock token
LOCK :: /document-webdav/72/-297102195.docx
PUT :: /document-webdav/72/-297102195.docx

Closing Doc passing previous token
UNLOCK :: /document-webdav/72/-297102195.docx



Sample headers on the first lock request to give client details

headers
"user-agent" : "Microsoft Office Word 2014 (16.0.7030) Windows NT 10.0", "x-office-major-version" : "16", "x-ms-cookieuri-requested" : "t", "x-featureversion" : "1", "x-msgetweburl" : "t", "x-idcrl_accepted" : "t", "accept-encoding" : "gzip", "transfer-encoding" : "chunked", "host" : "localhost:9008", "connection" : "Keep-Alive”

We are authenticating users using MS-OFBA.

Thank you,
Jason





_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users


_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users
Reply | Threaded
Open this post in threaded view
|

Re: Locking in Word

Jason Bradfield

We do offer the user an either view (ms-word:ofv) or edit(ms-word:ofe) links. But the word experience is no different.

We will need the user that opened it to read, to have the option to click edit in word to create the lock.

I am able to work around this, it feels it strange that I have instructed word to load as read and it tries to lock it before fetching the resource. And if I instruct word to open for edit word requests a lock then an unlock forcing the user to click edit in word to create another lock. Our locking database audit is being polluted with all the unnecessary locks being requested.

Jason.


From: Milton-users <[hidden email]> on behalf of Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 4:01 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Hi Jason,

Firstly, you do not need to use the Resource API in your situation. The annotations framework is equivalent to the Resource API. Simply use @ChildOf instead of @ChildrenOf

Word will attempt to lock the resource in order to open it for editing. The only way to prevent this would be to give the user a choice in your web application, and if they just want to view then to open a resource which does not support lock and other write methods.

/Brad


On 17/08/16 17:51, Jason Bradfield wrote:
Hi,

We are currently building a WebDav interface into our web based products document library.
Inside our product we allow users to lock and download documents. We are introducing WebDav to allow the users to open in Word and edit.

I have some questions regarding the behaviour we have seen. Although our implementation has just started so we may not be implementing the correct methods properly.
We are using the Resource interfaces as this fits better with our solution as we are not allowing users to mount using a filesystem, so we are not supporting any collection resources.

We have found that it does not matter if we open the document via ms-word:ofv|u|http://doc or ms-word:ofe|u|http://doc the experience is still the same.

See below for a sequence of calls from Word that we are seeing.

We propagate lock requests back to our database, where we are storing lock information.

My question is why is word trying to Lock and unlock the resource around an initial GET. Is there something we can do to prevent this. This will create a lot of noise in our database for people who just want to view the document. 


Open document
OPTIONS :: /document-webdav/72/
HEAD :: /document-webdav/72/-297102195.docx
OPTIONS :: /document-webdav/72/
LOCK :: /document-webdav/72/-297102195.docx
GET :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx
UNLOCK :: /document-webdav/72/-297102195.docx


Clicking Edit in Word
LOCK :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx


Saving... Uses previous lock token
LOCK :: /document-webdav/72/-297102195.docx
PUT :: /document-webdav/72/-297102195.docx

Closing Doc passing previous token
UNLOCK :: /document-webdav/72/-297102195.docx



Sample headers on the first lock request to give client details

headers
"user-agent" : "Microsoft Office Word 2014 (16.0.7030) Windows NT 10.0", "x-office-major-version" : "16", "x-ms-cookieuri-requested" : "t", "x-featureversion" : "1", "x-msgetweburl" : "t", "x-idcrl_accepted" : "t", "accept-encoding" : "gzip", "transfer-encoding" : "chunked", "host" : "localhost:9008", "connection" : "Keep-Alive”

We are authenticating users using MS-OFBA.

Thank you,
Jason





_______________________________________________
Milton-users mailing list
[hidden email]http://lists.justthe.net/mailman/listinfo/milton-users


_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users
Reply | Threaded
Open this post in threaded view
|

Re: Locking in Word

bradmacnz

Word will not attempt to lock a resource which does not support locking. So just have a url which identifies a Resource which does not implement locking, and use that for the read only view.

ie you might have something like ...

class EditableFileResource implements LockableResource, GetableResource, ReplaceableResource {

  private File file; // The edited resource

}

class ReadonlyFileResource implements GetableResource {

  private File file; // The viewed resource

}

EditableFileResource and ReadonlyFileResource are just 2 different views on the same underlying resource


and in your resource factory..

Resource getResource(host, path) {

File file = ... lookup the underlying resource;

if( path.startsWith("/readonly") ) {

  return new ReadonlyFileResource(file);

} else {

  return new EditableFileResource(file);

}

}




On 17/08/16 19:46, Jason Bradfield wrote:

We do offer the user an either view (ms-word:ofv) or edit(ms-word:ofe) links. But the word experience is no different.

We will need the user that opened it to read, to have the option to click edit in word to create the lock.

I am able to work around this, it feels it strange that I have instructed word to load as read and it tries to lock it before fetching the resource. And if I instruct word to open for edit word requests a lock then an unlock forcing the user to click edit in word to create another lock. Our locking database audit is being polluted with all the unnecessary locks being requested.

Jason.


From: Milton-users <[hidden email]> on behalf of Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 4:01 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Hi Jason,

Firstly, you do not need to use the Resource API in your situation. The annotations framework is equivalent to the Resource API. Simply use @ChildOf instead of @ChildrenOf

Word will attempt to lock the resource in order to open it for editing. The only way to prevent this would be to give the user a choice in your web application, and if they just want to view then to open a resource which does not support lock and other write methods.

/Brad


On 17/08/16 17:51, Jason Bradfield wrote:
Hi,

We are currently building a WebDav interface into our web based products document library.
Inside our product we allow users to lock and download documents. We are introducing WebDav to allow the users to open in Word and edit.

I have some questions regarding the behaviour we have seen. Although our implementation has just started so we may not be implementing the correct methods properly.
We are using the Resource interfaces as this fits better with our solution as we are not allowing users to mount using a filesystem, so we are not supporting any collection resources.

We have found that it does not matter if we open the document via ms-word:ofv|u|http://doc or ms-word:ofe|u|http://doc the experience is still the same.

See below for a sequence of calls from Word that we are seeing.

We propagate lock requests back to our database, where we are storing lock information.

My question is why is word trying to Lock and unlock the resource around an initial GET. Is there something we can do to prevent this. This will create a lot of noise in our database for people who just want to view the document. 


Open document
OPTIONS :: /document-webdav/72/
HEAD :: /document-webdav/72/-297102195.docx
OPTIONS :: /document-webdav/72/
LOCK :: /document-webdav/72/-297102195.docx
GET :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx
UNLOCK :: /document-webdav/72/-297102195.docx


Clicking Edit in Word
LOCK :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx


Saving... Uses previous lock token
LOCK :: /document-webdav/72/-297102195.docx
PUT :: /document-webdav/72/-297102195.docx

Closing Doc passing previous token
UNLOCK :: /document-webdav/72/-297102195.docx



Sample headers on the first lock request to give client details

headers
"user-agent" : "Microsoft Office Word 2014 (16.0.7030) Windows NT 10.0", "x-office-major-version" : "16", "x-ms-cookieuri-requested" : "t", "x-featureversion" : "1", "x-msgetweburl" : "t", "x-idcrl_accepted" : "t", "accept-encoding" : "gzip", "transfer-encoding" : "chunked", "host" : "localhost:9008", "connection" : "Keep-Alive”

We are authenticating users using MS-OFBA.

Thank you,
Jason





_______________________________________________
Milton-users mailing list
[hidden email]http://lists.justthe.net/mailman/listinfo/milton-users



_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users
Reply | Threaded
Open this post in threaded view
|

Re: Locking in Word

Jason Bradfield
That’s ok, But we want the user to be able to then within word allow editing. 

So I suppose the difference between open as read only compared to open to view then decide to edit.

Can I also ask, based on your example what tells word that is is read only, and not request a lock. i.e. The low level work milton does when we implement LockableResource or not.

From: Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 5:53 PM
To: Jason Bradfield <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Word will not attempt to lock a resource which does not support locking. So just have a url which identifies a Resource which does not implement locking, and use that for the read only view.

ie you might have something like ...

class EditableFileResource implements LockableResource, GetableResource, ReplaceableResource {

  private File file; // The edited resource

}

class ReadonlyFileResource implements GetableResource {

  private File file; // The viewed resource

}

EditableFileResource and ReadonlyFileResource are just 2 different views on the same underlying resource


and in your resource factory..

Resource getResource(host, path) {

File file = ... lookup the underlying resource;

if( path.startsWith("/readonly") ) {

  return new ReadonlyFileResource(file);

} else {

  return new EditableFileResource(file);

}

}




On 17/08/16 19:46, Jason Bradfield wrote:

We do offer the user an either view (ms-word:ofv) or edit(ms-word:ofe) links. But the word experience is no different.

We will need the user that opened it to read, to have the option to click edit in word to create the lock.

I am able to work around this, it feels it strange that I have instructed word to load as read and it tries to lock it before fetching the resource. And if I instruct word to open for edit word requests a lock then an unlock forcing the user to click edit in word to create another lock. Our locking database audit is being polluted with all the unnecessary locks being requested.

Jason.


From: Milton-users <[hidden email]> on behalf of Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 4:01 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Hi Jason,

Firstly, you do not need to use the Resource API in your situation. The annotations framework is equivalent to the Resource API. Simply use @ChildOf instead of @ChildrenOf

Word will attempt to lock the resource in order to open it for editing. The only way to prevent this would be to give the user a choice in your web application, and if they just want to view then to open a resource which does not support lock and other write methods.

/Brad


On 17/08/16 17:51, Jason Bradfield wrote:
Hi,

We are currently building a WebDav interface into our web based products document library.
Inside our product we allow users to lock and download documents. We are introducing WebDav to allow the users to open in Word and edit.

I have some questions regarding the behaviour we have seen. Although our implementation has just started so we may not be implementing the correct methods properly.
We are using the Resource interfaces as this fits better with our solution as we are not allowing users to mount using a filesystem, so we are not supporting any collection resources.

We have found that it does not matter if we open the document via ms-word:ofv|u|http://doc or ms-word:ofe|u|http://doc the experience is still the same.

See below for a sequence of calls from Word that we are seeing.

We propagate lock requests back to our database, where we are storing lock information.

My question is why is word trying to Lock and unlock the resource around an initial GET. Is there something we can do to prevent this. This will create a lot of noise in our database for people who just want to view the document. 


Open document
OPTIONS :: /document-webdav/72/
HEAD :: /document-webdav/72/-297102195.docx
OPTIONS :: /document-webdav/72/
LOCK :: /document-webdav/72/-297102195.docx
GET :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx
UNLOCK :: /document-webdav/72/-297102195.docx


Clicking Edit in Word
LOCK :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx


Saving... Uses previous lock token
LOCK :: /document-webdav/72/-297102195.docx
PUT :: /document-webdav/72/-297102195.docx

Closing Doc passing previous token
UNLOCK :: /document-webdav/72/-297102195.docx



Sample headers on the first lock request to give client details

headers
"user-agent" : "Microsoft Office Word 2014 (16.0.7030) Windows NT 10.0", "x-office-major-version" : "16", "x-ms-cookieuri-requested" : "t", "x-featureversion" : "1", "x-msgetweburl" : "t", "x-idcrl_accepted" : "t", "accept-encoding" : "gzip", "transfer-encoding" : "chunked", "host" : "localhost:9008", "connection" : "Keep-Alive”

We are authenticating users using MS-OFBA.

Thank you,
Jason





_______________________________________________
Milton-users mailing list
[hidden email]http://lists.justthe.net/mailman/listinfo/milton-users



_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users
Reply | Threaded
Open this post in threaded view
|

Re: Locking in Word

bradmacnz

Unfortunately we have no control over the UX workflow in Word.

Yes, milton reports capabilities to webdav clients through different fields in OPTIONS, HEAD and PROPFIND requests. Thats why there is the long sequence of requests to open a document. Word could be optimised to get that information in one request, but for some reason the major OS vendors never seem interested in that sort of optimisation.



On 17/08/16 20:08, Jason Bradfield wrote:
That’s ok, But we want the user to be able to then within word allow editing. 

So I suppose the difference between open as read only compared to open to view then decide to edit.

Can I also ask, based on your example what tells word that is is read only, and not request a lock. i.e. The low level work milton does when we implement LockableResource or not.

From: Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 5:53 PM
To: Jason Bradfield <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Word will not attempt to lock a resource which does not support locking. So just have a url which identifies a Resource which does not implement locking, and use that for the read only view.

ie you might have something like ...

class EditableFileResource implements LockableResource, GetableResource, ReplaceableResource {

  private File file; // The edited resource

}

class ReadonlyFileResource implements GetableResource {

  private File file; // The viewed resource

}

EditableFileResource and ReadonlyFileResource are just 2 different views on the same underlying resource


and in your resource factory..

Resource getResource(host, path) {

File file = ... lookup the underlying resource;

if( path.startsWith("/readonly") ) {

  return new ReadonlyFileResource(file);

} else {

  return new EditableFileResource(file);

}

}




On 17/08/16 19:46, Jason Bradfield wrote:

We do offer the user an either view (ms-word:ofv) or edit(ms-word:ofe) links. But the word experience is no different.

We will need the user that opened it to read, to have the option to click edit in word to create the lock.

I am able to work around this, it feels it strange that I have instructed word to load as read and it tries to lock it before fetching the resource. And if I instruct word to open for edit word requests a lock then an unlock forcing the user to click edit in word to create another lock. Our locking database audit is being polluted with all the unnecessary locks being requested.

Jason.


From: Milton-users <[hidden email]> on behalf of Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 4:01 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Hi Jason,

Firstly, you do not need to use the Resource API in your situation. The annotations framework is equivalent to the Resource API. Simply use @ChildOf instead of @ChildrenOf

Word will attempt to lock the resource in order to open it for editing. The only way to prevent this would be to give the user a choice in your web application, and if they just want to view then to open a resource which does not support lock and other write methods.

/Brad


On 17/08/16 17:51, Jason Bradfield wrote:
Hi,

We are currently building a WebDav interface into our web based products document library.
Inside our product we allow users to lock and download documents. We are introducing WebDav to allow the users to open in Word and edit.

I have some questions regarding the behaviour we have seen. Although our implementation has just started so we may not be implementing the correct methods properly.
We are using the Resource interfaces as this fits better with our solution as we are not allowing users to mount using a filesystem, so we are not supporting any collection resources.

We have found that it does not matter if we open the document via ms-word:ofv|u|http://doc or ms-word:ofe|u|http://doc the experience is still the same.

See below for a sequence of calls from Word that we are seeing.

We propagate lock requests back to our database, where we are storing lock information.

My question is why is word trying to Lock and unlock the resource around an initial GET. Is there something we can do to prevent this. This will create a lot of noise in our database for people who just want to view the document. 


Open document
OPTIONS :: /document-webdav/72/
HEAD :: /document-webdav/72/-297102195.docx
OPTIONS :: /document-webdav/72/
LOCK :: /document-webdav/72/-297102195.docx
GET :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx
UNLOCK :: /document-webdav/72/-297102195.docx


Clicking Edit in Word
LOCK :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx


Saving... Uses previous lock token
LOCK :: /document-webdav/72/-297102195.docx
PUT :: /document-webdav/72/-297102195.docx

Closing Doc passing previous token
UNLOCK :: /document-webdav/72/-297102195.docx



Sample headers on the first lock request to give client details

headers
"user-agent" : "Microsoft Office Word 2014 (16.0.7030) Windows NT 10.0", "x-office-major-version" : "16", "x-ms-cookieuri-requested" : "t", "x-featureversion" : "1", "x-msgetweburl" : "t", "x-idcrl_accepted" : "t", "accept-encoding" : "gzip", "transfer-encoding" : "chunked", "host" : "localhost:9008", "connection" : "Keep-Alive”

We are authenticating users using MS-OFBA.

Thank you,
Jason





_______________________________________________
Milton-users mailing list
[hidden email]http://lists.justthe.net/mailman/listinfo/milton-users




_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users
Reply | Threaded
Open this post in threaded view
|

Re: Locking in Word

Jason Bradfield

Thanks for your details, this is helping us.

I can see how the OPTIONS is returning the capabilities. i.e.
OPTIONS :: /document-webdav/72/ finished
headers
"DAV" : "1, 2, 3, calendar-access, calendarserver-principal-property-search, calendar-schedule, extended-mkcol, calendar-proxy, calendar-auto-schedule, schedule-inbox, schedule-outbox, addressbook", "MS-Author-Via" : "DAV", "Server" : "milton.io-2.0.0", "Date" : "Wed, 17 Aug 2016 05:05:43 GMT", "Accept-Ranges" : "bytes", "ETag" : ""72"", "Allow" : "GET, HEAD, PROPFIND, LOCK, OPTIONS, GET, HEAD, PROPPATCH, UNLOCK", "Content-Length" : "0", 
2016-08-17 15:05:43.056  INFO 12384 --- [nio-9008-exec-9] n.t.enquire.common.client.LogFilter      : HEAD :: /document-webdav/72/-297102195.docx start

But this seems to be on the Collection (directory) we will have resources (files) inside this directory that has a mix of Read Only and Editable(Lockable)



From: Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 6:14 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Unfortunately we have no control over the UX workflow in Word.

Yes, milton reports capabilities to webdav clients through different fields in OPTIONS, HEAD and PROPFIND requests. Thats why there is the long sequence of requests to open a document. Word could be optimised to get that information in one request, but for some reason the major OS vendors never seem interested in that sort of optimisation.



On 17/08/16 20:08, Jason Bradfield wrote:
That’s ok, But we want the user to be able to then within word allow editing. 

So I suppose the difference between open as read only compared to open to view then decide to edit.

Can I also ask, based on your example what tells word that is is read only, and not request a lock. i.e. The low level work milton does when we implement LockableResource or not.

From: Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 5:53 PM
To: Jason Bradfield <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Word will not attempt to lock a resource which does not support locking. So just have a url which identifies a Resource which does not implement locking, and use that for the read only view.

ie you might have something like ...

class EditableFileResource implements LockableResource, GetableResource, ReplaceableResource {

  private File file; // The edited resource

}

class ReadonlyFileResource implements GetableResource {

  private File file; // The viewed resource

}

EditableFileResource and ReadonlyFileResource are just 2 different views on the same underlying resource


and in your resource factory..

Resource getResource(host, path) {

File file = ... lookup the underlying resource;

if( path.startsWith("/readonly") ) {

  return new ReadonlyFileResource(file);

} else {

  return new EditableFileResource(file);

}

}




On 17/08/16 19:46, Jason Bradfield wrote:

We do offer the user an either view (ms-word:ofv) or edit(ms-word:ofe) links. But the word experience is no different.

We will need the user that opened it to read, to have the option to click edit in word to create the lock.

I am able to work around this, it feels it strange that I have instructed word to load as read and it tries to lock it before fetching the resource. And if I instruct word to open for edit word requests a lock then an unlock forcing the user to click edit in word to create another lock. Our locking database audit is being polluted with all the unnecessary locks being requested.

Jason.


From: Milton-users <[hidden email]> on behalf of Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 4:01 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Hi Jason,

Firstly, you do not need to use the Resource API in your situation. The annotations framework is equivalent to the Resource API. Simply use @ChildOf instead of @ChildrenOf

Word will attempt to lock the resource in order to open it for editing. The only way to prevent this would be to give the user a choice in your web application, and if they just want to view then to open a resource which does not support lock and other write methods.

/Brad


On 17/08/16 17:51, Jason Bradfield wrote:
Hi,

We are currently building a WebDav interface into our web based products document library.
Inside our product we allow users to lock and download documents. We are introducing WebDav to allow the users to open in Word and edit.

I have some questions regarding the behaviour we have seen. Although our implementation has just started so we may not be implementing the correct methods properly.
We are using the Resource interfaces as this fits better with our solution as we are not allowing users to mount using a filesystem, so we are not supporting any collection resources.

We have found that it does not matter if we open the document via ms-word:ofv|u|http://doc or ms-word:ofe|u|http://doc the experience is still the same.

See below for a sequence of calls from Word that we are seeing.

We propagate lock requests back to our database, where we are storing lock information.

My question is why is word trying to Lock and unlock the resource around an initial GET. Is there something we can do to prevent this. This will create a lot of noise in our database for people who just want to view the document. 


Open document
OPTIONS :: /document-webdav/72/
HEAD :: /document-webdav/72/-297102195.docx
OPTIONS :: /document-webdav/72/
LOCK :: /document-webdav/72/-297102195.docx
GET :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx
UNLOCK :: /document-webdav/72/-297102195.docx


Clicking Edit in Word
LOCK :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx


Saving... Uses previous lock token
LOCK :: /document-webdav/72/-297102195.docx
PUT :: /document-webdav/72/-297102195.docx

Closing Doc passing previous token
UNLOCK :: /document-webdav/72/-297102195.docx



Sample headers on the first lock request to give client details

headers
"user-agent" : "Microsoft Office Word 2014 (16.0.7030) Windows NT 10.0", "x-office-major-version" : "16", "x-ms-cookieuri-requested" : "t", "x-featureversion" : "1", "x-msgetweburl" : "t", "x-idcrl_accepted" : "t", "accept-encoding" : "gzip", "transfer-encoding" : "chunked", "host" : "localhost:9008", "connection" : "Keep-Alive”

We are authenticating users using MS-OFBA.

Thank you,
Jason





_______________________________________________
Milton-users mailing list
[hidden email]http://lists.justthe.net/mailman/listinfo/milton-users




_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users
Reply | Threaded
Open this post in threaded view
|

Re: Locking in Word

bradmacnz

Word does a mixture, most capabilities are reported through OPTIONS on the mount point. The HEAD and PROPFIND requests are also used for certain capability discovery, but i actually cant remember whether Word will correctly interpret capabilities per resource within a collection.

It might be necessary to have 2 different collections containing different views on the same resources, possibly by adding a path segment. Eg

/document-webdav/writable/72/-297102195.docx

/document-webdav/readonly/72/-297102195.docx

Make sure that the collection representing the /readonly/ path segment does not implement LockingCollectionResource

On 18/08/16 12:08, Jason Bradfield wrote:

Thanks for your details, this is helping us.

I can see how the OPTIONS is returning the capabilities. i.e.
OPTIONS :: /document-webdav/72/ finished
headers
"DAV" : "1, 2, 3, calendar-access, calendarserver-principal-property-search, calendar-schedule, extended-mkcol, calendar-proxy, calendar-auto-schedule, schedule-inbox, schedule-outbox, addressbook", "MS-Author-Via" : "DAV", "Server" : "milton.io-2.0.0", "Date" : "Wed, 17 Aug 2016 05:05:43 GMT", "Accept-Ranges" : "bytes", "ETag" : ""72"", "Allow" : "GET, HEAD, PROPFIND, LOCK, OPTIONS, GET, HEAD, PROPPATCH, UNLOCK", "Content-Length" : "0", 
2016-08-17 15:05:43.056  INFO 12384 --- [nio-9008-exec-9] n.t.enquire.common.client.LogFilter      : HEAD :: /document-webdav/72/-297102195.docx start

But this seems to be on the Collection (directory) we will have resources (files) inside this directory that has a mix of Read Only and Editable(Lockable)



From: Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 6:14 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Unfortunately we have no control over the UX workflow in Word.

Yes, milton reports capabilities to webdav clients through different fields in OPTIONS, HEAD and PROPFIND requests. Thats why there is the long sequence of requests to open a document. Word could be optimised to get that information in one request, but for some reason the major OS vendors never seem interested in that sort of optimisation.



On 17/08/16 20:08, Jason Bradfield wrote:
That’s ok, But we want the user to be able to then within word allow editing. 

So I suppose the difference between open as read only compared to open to view then decide to edit.

Can I also ask, based on your example what tells word that is is read only, and not request a lock. i.e. The low level work milton does when we implement LockableResource or not.

From: Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 5:53 PM
To: Jason Bradfield <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Word will not attempt to lock a resource which does not support locking. So just have a url which identifies a Resource which does not implement locking, and use that for the read only view.

ie you might have something like ...

class EditableFileResource implements LockableResource, GetableResource, ReplaceableResource {

  private File file; // The edited resource

}

class ReadonlyFileResource implements GetableResource {

  private File file; // The viewed resource

}

EditableFileResource and ReadonlyFileResource are just 2 different views on the same underlying resource


and in your resource factory..

Resource getResource(host, path) {

File file = ... lookup the underlying resource;

if( path.startsWith("/readonly") ) {

  return new ReadonlyFileResource(file);

} else {

  return new EditableFileResource(file);

}

}




On 17/08/16 19:46, Jason Bradfield wrote:

We do offer the user an either view (ms-word:ofv) or edit(ms-word:ofe) links. But the word experience is no different.

We will need the user that opened it to read, to have the option to click edit in word to create the lock.

I am able to work around this, it feels it strange that I have instructed word to load as read and it tries to lock it before fetching the resource. And if I instruct word to open for edit word requests a lock then an unlock forcing the user to click edit in word to create another lock. Our locking database audit is being polluted with all the unnecessary locks being requested.

Jason.


From: Milton-users <[hidden email]> on behalf of Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 4:01 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Hi Jason,

Firstly, you do not need to use the Resource API in your situation. The annotations framework is equivalent to the Resource API. Simply use @ChildOf instead of @ChildrenOf

Word will attempt to lock the resource in order to open it for editing. The only way to prevent this would be to give the user a choice in your web application, and if they just want to view then to open a resource which does not support lock and other write methods.

/Brad


On 17/08/16 17:51, Jason Bradfield wrote:
Hi,

We are currently building a WebDav interface into our web based products document library.
Inside our product we allow users to lock and download documents. We are introducing WebDav to allow the users to open in Word and edit.

I have some questions regarding the behaviour we have seen. Although our implementation has just started so we may not be implementing the correct methods properly.
We are using the Resource interfaces as this fits better with our solution as we are not allowing users to mount using a filesystem, so we are not supporting any collection resources.

We have found that it does not matter if we open the document via ms-word:ofv|u|http://doc or ms-word:ofe|u|http://doc the experience is still the same.

See below for a sequence of calls from Word that we are seeing.

We propagate lock requests back to our database, where we are storing lock information.

My question is why is word trying to Lock and unlock the resource around an initial GET. Is there something we can do to prevent this. This will create a lot of noise in our database for people who just want to view the document. 


Open document
OPTIONS :: /document-webdav/72/
HEAD :: /document-webdav/72/-297102195.docx
OPTIONS :: /document-webdav/72/
LOCK :: /document-webdav/72/-297102195.docx
GET :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx
UNLOCK :: /document-webdav/72/-297102195.docx


Clicking Edit in Word
LOCK :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx


Saving... Uses previous lock token
LOCK :: /document-webdav/72/-297102195.docx
PUT :: /document-webdav/72/-297102195.docx

Closing Doc passing previous token
UNLOCK :: /document-webdav/72/-297102195.docx



Sample headers on the first lock request to give client details

headers
"user-agent" : "Microsoft Office Word 2014 (16.0.7030) Windows NT 10.0", "x-office-major-version" : "16", "x-ms-cookieuri-requested" : "t", "x-featureversion" : "1", "x-msgetweburl" : "t", "x-idcrl_accepted" : "t", "accept-encoding" : "gzip", "transfer-encoding" : "chunked", "host" : "localhost:9008", "connection" : "Keep-Alive”

We are authenticating users using MS-OFBA.

Thank you,
Jason





_______________________________________________
Milton-users mailing list
[hidden email]http://lists.justthe.net/mailman/listinfo/milton-users





_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users
Reply | Threaded
Open this post in threaded view
|

Re: Locking in Word

Jason Bradfield
That is my approach if I can’t do it on a file basis. It will just move that logic to a different location in our application. i.e. It needs to be determined before the webdav call.

Thanks.

From: Brad McEvoy <[hidden email]>
Date: Thursday, 18 August 2016 at 10:31 AM
To: Jason Bradfield <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Word does a mixture, most capabilities are reported through OPTIONS on the mount point. The HEAD and PROPFIND requests are also used for certain capability discovery, but i actually cant remember whether Word will correctly interpret capabilities per resource within a collection.

It might be necessary to have 2 different collections containing different views on the same resources, possibly by adding a path segment. Eg

/document-webdav/writable/72/-297102195.docx

/document-webdav/readonly/72/-297102195.docx

Make sure that the collection representing the /readonly/ path segment does not implement LockingCollectionResource

On 18/08/16 12:08, Jason Bradfield wrote:

Thanks for your details, this is helping us.

I can see how the OPTIONS is returning the capabilities. i.e.
OPTIONS :: /document-webdav/72/ finished
headers
"DAV" : "1, 2, 3, calendar-access, calendarserver-principal-property-search, calendar-schedule, extended-mkcol, calendar-proxy, calendar-auto-schedule, schedule-inbox, schedule-outbox, addressbook", "MS-Author-Via" : "DAV", "Server" : "milton.io-2.0.0", "Date" : "Wed, 17 Aug 2016 05:05:43 GMT", "Accept-Ranges" : "bytes", "ETag" : ""72"", "Allow" : "GET, HEAD, PROPFIND, LOCK, OPTIONS, GET, HEAD, PROPPATCH, UNLOCK", "Content-Length" : "0", 
2016-08-17 15:05:43.056  INFO 12384 --- [nio-9008-exec-9] n.t.enquire.common.client.LogFilter      : HEAD :: /document-webdav/72/-297102195.docx start

But this seems to be on the Collection (directory) we will have resources (files) inside this directory that has a mix of Read Only and Editable(Lockable)



From: Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 6:14 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Unfortunately we have no control over the UX workflow in Word.

Yes, milton reports capabilities to webdav clients through different fields in OPTIONS, HEAD and PROPFIND requests. Thats why there is the long sequence of requests to open a document. Word could be optimised to get that information in one request, but for some reason the major OS vendors never seem interested in that sort of optimisation.



On 17/08/16 20:08, Jason Bradfield wrote:
That’s ok, But we want the user to be able to then within word allow editing. 

So I suppose the difference between open as read only compared to open to view then decide to edit.

Can I also ask, based on your example what tells word that is is read only, and not request a lock. i.e. The low level work milton does when we implement LockableResource or not.

From: Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 5:53 PM
To: Jason Bradfield <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Word will not attempt to lock a resource which does not support locking. So just have a url which identifies a Resource which does not implement locking, and use that for the read only view.

ie you might have something like ...

class EditableFileResource implements LockableResource, GetableResource, ReplaceableResource {

  private File file; // The edited resource

}

class ReadonlyFileResource implements GetableResource {

  private File file; // The viewed resource

}

EditableFileResource and ReadonlyFileResource are just 2 different views on the same underlying resource


and in your resource factory..

Resource getResource(host, path) {

File file = ... lookup the underlying resource;

if( path.startsWith("/readonly") ) {

  return new ReadonlyFileResource(file);

} else {

  return new EditableFileResource(file);

}

}




On 17/08/16 19:46, Jason Bradfield wrote:

We do offer the user an either view (ms-word:ofv) or edit(ms-word:ofe) links. But the word experience is no different.

We will need the user that opened it to read, to have the option to click edit in word to create the lock.

I am able to work around this, it feels it strange that I have instructed word to load as read and it tries to lock it before fetching the resource. And if I instruct word to open for edit word requests a lock then an unlock forcing the user to click edit in word to create another lock. Our locking database audit is being polluted with all the unnecessary locks being requested.

Jason.


From: Milton-users <[hidden email]> on behalf of Brad McEvoy <[hidden email]>
Date: Wednesday, 17 August 2016 at 4:01 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: [Milton-users] Locking in Word

Hi Jason,

Firstly, you do not need to use the Resource API in your situation. The annotations framework is equivalent to the Resource API. Simply use @ChildOf instead of @ChildrenOf

Word will attempt to lock the resource in order to open it for editing. The only way to prevent this would be to give the user a choice in your web application, and if they just want to view then to open a resource which does not support lock and other write methods.

/Brad


On 17/08/16 17:51, Jason Bradfield wrote:
Hi,

We are currently building a WebDav interface into our web based products document library.
Inside our product we allow users to lock and download documents. We are introducing WebDav to allow the users to open in Word and edit.

I have some questions regarding the behaviour we have seen. Although our implementation has just started so we may not be implementing the correct methods properly.
We are using the Resource interfaces as this fits better with our solution as we are not allowing users to mount using a filesystem, so we are not supporting any collection resources.

We have found that it does not matter if we open the document via ms-word:ofv|u|http://doc or ms-word:ofe|u|http://doc the experience is still the same.

See below for a sequence of calls from Word that we are seeing.

We propagate lock requests back to our database, where we are storing lock information.

My question is why is word trying to Lock and unlock the resource around an initial GET. Is there something we can do to prevent this. This will create a lot of noise in our database for people who just want to view the document. 


Open document
OPTIONS :: /document-webdav/72/
HEAD :: /document-webdav/72/-297102195.docx
OPTIONS :: /document-webdav/72/
LOCK :: /document-webdav/72/-297102195.docx
GET :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx
UNLOCK :: /document-webdav/72/-297102195.docx


Clicking Edit in Word
LOCK :: /document-webdav/72/-297102195.docx
PROPFIND :: /document-webdav/72/-297102195.docx
HEAD :: /document-webdav/72/-297102195.docx


Saving... Uses previous lock token
LOCK :: /document-webdav/72/-297102195.docx
PUT :: /document-webdav/72/-297102195.docx

Closing Doc passing previous token
UNLOCK :: /document-webdav/72/-297102195.docx



Sample headers on the first lock request to give client details

headers
"user-agent" : "Microsoft Office Word 2014 (16.0.7030) Windows NT 10.0", "x-office-major-version" : "16", "x-ms-cookieuri-requested" : "t", "x-featureversion" : "1", "x-msgetweburl" : "t", "x-idcrl_accepted" : "t", "accept-encoding" : "gzip", "transfer-encoding" : "chunked", "host" : "localhost:9008", "connection" : "Keep-Alive”

We are authenticating users using MS-OFBA.

Thank you,
Jason





_______________________________________________
Milton-users mailing list
[hidden email]http://lists.justthe.net/mailman/listinfo/milton-users





_______________________________________________
Milton-users mailing list
[hidden email]
http://lists.justthe.net/mailman/listinfo/milton-users