Hello,

since I have not found anything on CardDAV related/written in/for FreePascal/Lazarus, (haven't googled with Delphi keyword thou)

I'd like to send out some smoke signals, asking which way would the support for this kind of interaction (dare not call it a protocol) would be best fitting into FreePascal/Lazarus world.

CardDAV itself is an extension of WebDAV and itself has its own RFC (RFC6532).

I myself am trying to write a client connecting via CardDAV to a compatible server (built into my CRM, eGroupware) to request search and read addressbook entries.

(it was the developers of the CRM in question indicated to me that XMLRPC is dead and support for it will be removed when they get a chance - that's why I'm doing this.)

So far I got as far as copy/pasting example XML from the RFC and got a valid response from server, using THTTPSend from Synapse. http://wiki.freepascal.org/XML_Tutorial (and particularly the second XML2Tree procedure from http://wiki.freepascal.org/XML_Tutorial#Populating_a_TreeView_with_XML, with some mod of mine to not pass a TTreeView but a TTreeNodes object into it instead) came in handy to understand the structure of it.

There are certain advantages of CardDAV over XMLRPC, which this post is too short to contain ;)

I intend to keep it very simple at first, as it's enough for my purpose, to the point that the XML elements+attributes would be coded just as string concatenating operations and validated using TXMLDocument from dom.pas.
Seems like the more complicated elements of DOM level 3 will need DOM.pas modifications too.

But I'd like to know, if there is interest in making it 'more sentient', e.g. as a TDataSource/TDataSet descendant directly talking to (reading, at first) DOM.pas's TXMLDocument/TDOMDocument, then to a THTMLSend or any such class of your liking?

Please let me know your thoughts :)

Kind Regards
Lukasz

Lukasz Sokol wrote

Seems like the more complicated elements of DOM level 3 will need DOM.pas modifications too.

What kind of modification ?

I have sent this patch [1] to allow create custom descendants of TDomElement. You can check whether this could be useful to you.

I believe at least two more methods[2] need to be changed.

The patch is meant to modify dom.pas, but maybe I should have made it to laz2_dom, as it seems to have more attention these days(being update to UTF8 I Believe).

By the way, feedback (is a viable suggestion, no, why..?) on this subject would be appreciated.

[1] http://bugs.freepascal.org/view.php?id=24860
[2] CreateElement and CreateElementBuf

Uh, you got me - I don't know as I haven't started yet... I was merely referring to what dom.pas has at the top of itself:

DOM Level 3 - Partially implemented

so I should have phrased it differently :

"It remains to be seen whether any DOM Level 3 additions will be needed into DOM.pas since it states it's Partially Implemented"

I have sent this patch [1] to allow create custom descendants of TDomElement. You can check whether this could be useful to you.

Noted, I for now am very very early in this so I can't tell.

(mental note: check las2_dom.)

By the way, feedback (is a viable suggestion, no, why..?) on this subject would be appreciated.

Of course I will give feedback when (and if) I get any.

For now, I was merely asking, what direction the development should take, and whether it's a good idea to make it into a Data Access palette component like T*DataSet, or is it 'overkill'.

[1] http://bugs.freepascal.org/view.php?id=24860 [2] CreateElement and CreateElementBuf

Thanks for your reply,

Kind Regards,
Lukasz

Well, it would be nice to have a dataset encapsulation but perhaps your time would be better spent on CalDAV support (grins, ducks & runs...) ;)

Well, let's not say 'hop' before landing on the other side of the ditch ;)

CalDAV itself is used on the CRM I use, but I've no demand for interacting with it. Yet.*

From fiddling with open coded HTTP Requests, I'm so far getting open coded vCard's

as string ;)

(*and probably applications like Sunbird/Lightning are better for it anyway*)

-L.

I was talking about the dom/laz2_dom feedback.

But your feedback will be welcomed as well.

Daniel Gaspary wrote

I was talking about the dom/laz2_dom feedback.

I was talking about the dom/laz2_dom DEVELOPERS feedback.

(Just Correcting myself)

I do not think that a TDataset descendent is needed. A simple collection based class will do just fine, and a class to handle transport. I have one for WebDAV, and CardDav really is not so much different.

I also do not see why you would need alterations to DOM.pas, both WebDav and CardDav use plain and simple XML.

BTW. The RFC is 6352 instead of 6532.

Michael.

Thank you for applying the patch, Michael.

As soon as I have some time I will send another one related to the same case.

Lukasz Sokol wrote

CalDAV itself is used on the CRM I use, but I've no demand for interacting with it. Yet.*

I have just taken a look at the RFC* and it seems simple to implement.

I don't need CardDav right now, but I believe I will need it soon.

Can you take (and share) CardDav samples needed on this CRM? They could be useful.

* http://tools.ietf.org/html/rfc6352#page-4

"Lukasz Sokol" wrote

Please let me know your thoughts :)

I personally would prefer if such protocol implementations are independant of the socket classes used so I can use it with FPC's sockets, lNet, Synapse or whatever.

Basically this would need a abstract class which is called by the protocol implementation and is implemented for each "socket" class. And also methods inside the protocol implementation that can be called by the "socket" class.

I've done this as a modification for a Delphi-only Synapse (AFAIK) using MQTT implementation and it works quite well in FPC with lNet :)

Regards,
Sven

Exactly.

Hence my suggestion for a separate class to handle transport.

Michael.

So far, I c&p the examples included in the RFC (OPTIONS, REPORT/CARDDAV:addressbook-multiget) pasting into my program as plain text and it sure enough works; maybe not a briliant way to do things, but it does (in the sense that it produces output I expect).

Due to quite a short time I spent on it so far, I haven't delved much deeper into using the DOM.pas (or indeed any other abstract XML class) directly - all it does for me so far, is validation of XML and mid-point to a more visual representation of it into TTreeNodes, which ultimately isn't needed but helps me imagine what's going on.

* http://tools.ietf.org/html/rfc6352#page-4

(I'll continue in other replies to MvC in this thread)

Thanks,
-Lukasz

[...]

So far fiddling with plain text queries, I'm consistently getting contents of vcards that I expect to get [through REPORT method]

I think I should focus on more 'low hanging fruit' for now : building the xml CardDAV query using the TXMLDocument* class, as I pass it to Synapse's THTMLSend.Document later anyway, and handling of what's received through the same TXMLDocument*.

(* out of whichever *DOM.pas comes to use eventually)

When that's done, we'll think of higher levels
(one immediately comes to mind - vCard handling.)

I also do not see why you would need alterations to DOM.pas, both WebDav and CardDav use plain and simple XML.

I merely based my assumption on DOM.pas comment stating level3 is partially implemented... should have worded it differently:

"It remains to be seen whether any DOM Level 3 additions will be needed into DOM.pas since it states it's Partially Implemented"

BTW. The RFC is 6352 instead of 6532.

yeah. sorry 'bout that too :)

-L.

I understood you correctly.

DOM is an implementation specification. Not an XML specification.

DOM "level 3" has nothing to do with the ability to process XML. DOM "level 2" will just as well parse any valid XML.

The only thing DOM level 3 will probably give you is perhaps some extra methods/properties to make life easier.

Just tring to point out that you should be fine with the dom unit as it is, before you go chasing ghosts and spend time on things that are not essential :)

Michael.

Noted, thanks - so far haven't got as far as using dom.pas directly, yet. But I wanted to experiment with open text xml with different queries first, then translate into direct dom.pas usage.

Low hanging fruit ;) and time constraints.

-L.

Ah, now I found the sentence where you mentioned this :)

Regards,
Sven