hello,
as of integrating carddav with an ikiwiki, i'd like to link to a particular contact in carddavmate.
my idea is to dissect the fragment identifier of the url once the page is loaded, and if the fragment identifier is found on the server, it is opened right away
so eg.
http://my_server/carddavmate/#/jdoe/addresses/1234-5678-90ab-cdef.vcf
would open the described contact in jdoe's address book (or whatever the semantics of the webdav server are) for viewing.
two issues are to be considered imo:
* authentication: if the setup needs authentication, the fragment identifier should be analyzed once login is complete. (that's where i failed to write a patch -- i could have found *some* place to invoke `globalAddressbookList.loadContactByUID()`, but not *the right* place). many such setups will already use some kind of single sign on solution (even simply basic http authentication) and won't require a login step. * identifiers might need to contain data describing which server the resource is on, possibly just the complete url. carddavmate should not expect to find the user name as part of the url, though.
would you consider adding this feature?
that whole scheme could be extended to directly edit (#/file.vcf?edit) or for search queries (#?search=john), but something basic would give good entry points for bigger setups, i think. likewise, actively rewriting the fragment identifer might get carddavmate a working back-button and an easy way to forward links to "the contact i have open right now", but that too is just my idea of where this feature could lead.
thanks for maintaining carddavmate and caldavzap, i'm actively using them with radicale, and they work great!
best regards chrysn
Hi Chrysn,
On Jul 9, 2013, at 4:38 PM, chrysn chrysn@fsfe.org wrote:
hello,
as of integrating carddav with an ikiwiki, i'd like to link to a particular contact in carddavmate.
my idea is to dissect the fragment identifier of the url once the page is loaded, and if the fragment identifier is found on the server, it is opened right away
so eg.
http://my_server/carddavmate/#/jdoe/addresses/1234-5678-90ab-cdef.vcf
would open the described contact in jdoe's address book (or whatever the semantics of the webdav server are) for viewing.
two issues are to be considered imo:
- authentication: if the setup needs authentication, the fragment
identifier should be analyzed once login is complete. (that's where i failed to write a patch -- i could have found *some* place to invoke `globalAddressbookList.loadContactByUID()`, but not *the right* place). many such setups will already use some kind of single sign on solution (even simply basic http authentication) and won't require a login step.
- identifiers might need to contain data describing which server the
resource is on, possibly just the complete url. carddavmate should not expect to find the user name as part of the url, though.
would you consider adding this feature?
Sorry but I don't fully understand the design of your "integration" - maybe a demo URL can help to understand it.
UID change in CardDavMATE (e.g. http://username@server:port/principal_url/object.vcf) is very bad idea, because I support multiple logins to the SAME principal URL with different username - so the login name MUST be a part of UID.
JM
that whole scheme could be extended to directly edit (#/file.vcf?edit) or for search queries (#?search=john), but something basic would give good entry points for bigger setups, i think. likewise, actively rewriting the fragment identifer might get carddavmate a working back-button and an easy way to forward links to "the contact i have open right now", but that too is just my idea of where this feature could lead.
thanks for maintaining carddavmate and caldavzap, i'm actively using them with radicale, and they work great!
best regards chrysn
-- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
On Wed, Jul 10, 2013 at 01:21:48AM +0200, Ján Máté wrote:
Sorry but I don't fully understand the design of your "integration" - maybe a demo URL can help to understand it.
on your test system,
http://www.inf-it.com/carddavmate/#http://www.inf-it.com:80/proxy/caldav.php...
should open the contact "Picard Jean-Luc" in the colleagues address book.
UID change in CardDavMATE (e.g. http://username@server:port/principal_url/object.vcf) is very bad idea, because I support multiple logins to the SAME principal URL with different username - so the login name MUST be a part of UID.
the reason why i stripped the 'test@inf-it.com@' from aftert the '#http://' in the above url is the basic assumption that an http resource (and, in particular, a webdav or carddav one) is basically independent of by which credentials it is accessed, and in general one can't predict which credentials the one who finally resolves the link will have available.
the implementation could even accept links with user name, but should be prepared to search the available address books for one that matches if stripped off the user name and open that one. in pseudocode:
requested_resource = window.location.hash requested_host = get_host_part(requested_resource) for current_principal in available_principals: if requested_resource starts with remove_username(current_principal): open requested_resource, replacing remove_username(current_principal) with current_principal
i don't know where we should talk of host names and where of principals here, but do you see what i mean?
best regards chrysn
On Jul 10, 2013, at 10:01 AM, chrysn chrysn@fsfe.org wrote:
On Wed, Jul 10, 2013 at 01:21:48AM +0200, Ján Máté wrote:
Sorry but I don't fully understand the design of your "integration" - maybe a demo URL can help to understand it.
on your test system,
http://www.inf-it.com/carddavmate/#http://www.inf-it.com:80/proxy/caldav.php...
should open the contact "Picard Jean-Luc" in the colleagues address book.
Okej, now I understand but this idea is VERY crazy, because the client can open a contact ONLY after performs full sync with the server. So in reality it can take lot of seconds - for example if you have 1000 contacts, then it loads all of them and only then opens the "selected" contact from the URL. Another problem is, that if you click to second "contact URL" then the browser will RELOAD the whole software, re-syncs all contacts and only then opens the second contact.
UID change in CardDavMATE (e.g. http://username@server:port/principal_url/object.vcf) is very bad idea, because I support multiple logins to the SAME principal URL with different username - so the login name MUST be a part of UID.
the reason why i stripped the 'test@inf-it.com@' from aftert the '#http://' in the above url is the basic assumption that an http resource (and, in particular, a webdav or carddav one) is basically independent of by which credentials it is accessed, and in general one can't predict which credentials the one who finally resolves the link will have available.
the implementation could even accept links with user name, but should be prepared to search the available address books for one that matches if stripped off the user name and open that one. in pseudocode:
requested_resource = window.location.hash requested_host = get_host_part(requested_resource) for current_principal in available_principals: if requested_resource starts with remove_username(current_principal): open requested_resource, replacing remove_username(current_principal) with current_principal
i don't know where we should talk of host names and where of principals here, but do you see what i mean?
In CardDavMATE you can configure an array of accounts, for example:
[1]: Principal URL: https://server.com:8443/caldav.php/cars/bmw/ Username/Password: test/test [2]: Principal URL: https://server.com:8443/caldav.php/cars/bmw/ <-- identical principal URL Username/Password: test2/test2 <-- different user
then it loads all contacts from both accounts (each contact is loaded twice because the principal URL is the same). In the interface you will see only contacts from the selected addressbook (contacts from different addressbooks are "hidden") but in future I will add support for displaying all loaded contacts from all accounts/addressbooks. Then if you edit a contact and click to "Save", the PUT request requires the login name (because user A and user B privileges can be different). And this login name is extracted from the object UID - the client finds the proper account and use the proper password (in the Auth header) for the PUT request.
As you see the login name is REALLY required in the UID because it must be globally unique. Heuristic search on the UID value is VERY bad idea, because it requires sequential search and for performance reason I use hash - the key is the UID and the value is the destination object.
JM
best regards chrysn
-- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
On Wed, Jul 10, 2013 at 04:30:42PM +0200, Ján Máté wrote:
Okej, now I understand but this idea is VERY crazy, because the client can open a contact ONLY after performs full sync with the server. So in reality it can take lot of seconds - for example if you have 1000 contacts, then it loads all of them and only then opens the "selected" contact from the URL. Another problem is, that if you click to second "contact URL" then the browser will RELOAD the whole software, re-syncs all contacts and only then opens the second contact.
but it wouldn't take longer than opening caldavmate directly, would it? (as it would happen with a "see it's a contact" / "open carddavmate" / "look it up there" workflow)
enhancements in caching could reduce that time, but for the time being, loading the complete calendar would be completely acceptable in my setup.
As you see the login name is REALLY required in the UID because it must be globally unique. Heuristic search on the UID value is VERY bad idea, because it requires sequential search and for performance reason I use hash - the key is the UID and the value is the destination object.
it would be possible to work with a complete url too. (for the time being, there could be a generic "web-access" user.) if the base hook is implemented, i might be able to use it as a starting point and experiment with optimizations that would work without sequential search.
(my javascript is a little rusty, especially when it comes to interfacing with the web browser part, but when it comes to algorithms, it's just another programming language.)
best regards chrysn
On Jul 10, 2013, at 5:46 PM, chrysn chrysn@fsfe.org wrote:
On Wed, Jul 10, 2013 at 04:30:42PM +0200, Ján Máté wrote:
but it wouldn't take longer than opening caldavmate directly, would it?
yes, this is true
(as it would happen with a "see it's a contact" / "open carddavmate" / "look it up there" workflow)
enhancements in caching could reduce that time, but for the time being, loading the complete calendar would be completely acceptable in my setup.
I have plan to use HTML5 "offline cache" in future (there are lot of problems with the current implementations in different browsers)
As you see the login name is REALLY required in the UID because it must be globally unique. Heuristic search on the UID value is VERY bad idea, because it requires sequential search and for performance reason I use hash - the key is the UID and the value is the destination object.
it would be possible to work with a complete url too. (for the time being, there could be a generic "web-access" user.) if the base hook is implemented, i might be able to use it as a starting point and experiment with optimizations that would work without sequential search.
If you want a "default" user then why it is a problem to add this user to URL?
If you use globalAccountSettings instead of globalNetworkCheckSettings then the system will automatically login with default credentials (set in globalAccountSettings) and you can add the same user to the URL ...
... then you can use the loadContactByUID function
JM
(my javascript is a little rusty, especially when it comes to interfacing with the web browser part, but when it comes to algorithms, it's just another programming language.)
best regards chrysn
On Thu, Jul 11, 2013 at 12:24:51PM +0200, Ján Máté wrote:
I have plan to use HTML5 "offline cache" in future (there are lot of problems with the current implementations in different browsers)
do you think it would be feasible to leverage the web browser's cache on the REPORT queries (based on ETag / If-None-Match)? that would only hit the cache if the address book was not changed *at all* since the last access, but would give great speedup in those cases.
If you want a "default" user then why it is a problem to add this user to URL?
the original scenario i thought of would have involved individual users, but as it's more difficult, i can resort to such a default user option.
that would make implementation in cardavmate easier in the first place; we could fiddle with the details later, i'd just need help with the original hook.
best regards and thanks for your fast responses chrysn
On Jul 11, 2013, at 12:34 PM, chrysn chrysn@fsfe.org wrote:
On Thu, Jul 11, 2013 at 12:24:51PM +0200, Ján Máté wrote:
I have plan to use HTML5 "offline cache" in future (there are lot of problems with the current implementations in different browsers)
do you think it would be feasible to leverage the web browser's cache on the REPORT queries (based on ETag / If-None-Match)? that would only hit the cache if the address book was not changed *at all* since the last access, but would give great speedup in those cases.
Yes, this is exactly what I want ... offline storage in browser (with encryption), this feature is on my long term roadmap.
If you want a "default" user then why it is a problem to add this user to URL?
the original scenario i thought of would have involved individual users, but as it's more difficult, i can resort to such a default user option.
that would make implementation in cardavmate easier in the first place; we could fiddle with the details later, i'd just need help with the original hook.
With globalAccountSettings and default user it is very simple ... it requires changes only in 1-2 functions ... good starting point is the selectActiveAddressbook function (it selects the default addressbook /if it is set in settings/ or the first addressbook) and if it is loaded your need to call only the loadContactByUID (or generate an onclick event on the specified contact + you can generate another onclick event on edit button or anything else) ...
JM
best regards and thanks for your fast responses chrysn
-- I shouldn't have written all those tank programs. -- Kevin Flynn
-
chrysn -
Ján Máté