[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Inf-IT DAVcl] accessing particular vcard files


On Jul 10, 2013, at 5:46 PM, chrysn <chrysn@xxxxxxxx> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature


Follow-Ups:
Re: [Inf-IT DAVcl] accessing particular vcard fileschrysn <chrysn@xxxxxxxx>