API question

[ste...@niteflyte.net]

I'm using saber/dav 3.1.4.  I've written some utilities to create/manage:

- users

- calendars

- address books

However, the SQLite database schema has changed for 3.2.0.  I realize there's a db migration process but I need to update my utilities because there were schema changes.

Is there a sabre/dav API for doing this stuff.  Specifically, I need to

- add/update/delete users

- add new calendars/address books

- update calendars/address books (change the name mostly)

- delete calendars/address books

- count entries in calendars/address books

Can you point me to relevant docs or am I just to do this by the seat of my pants (studying the db schema) like I did the first time?

My user base is very small (4 Mac laptops, 4 iPhones and 1 iPad) so scalability is not really an issue.  I just want to isolate my utilities from schema changes in the future.

I can send you the code if there's any interest.  It's packaged pretty well.

Thanks in advance!

--

Steve Witten

Portland, OR

[ste...@niteflyte.net]

On Friday, January 13, 2017 at 1:42:59 PM UTC-8, ste...@niteflyte.net wrote:

I'm using saber/dav 3.1.4.  I've written some utilities to create/manage:

- users

- calendars

- address books

Oh yeah... enumerate users/calendars/address books too.

-- sw 

[Evert Pot]

Hi Stevewi,

Take a look at the PDO objects. In your server.php you're instantiating
them. Each of those represent all the data-storage methods for these
types of operations.

For example Sabre\CalDAV\Backend\PDO. The classes themselves are pretty
well documented.

Hope this helps,
Evert

[ste...@niteflyte.net]

Thanks Evert!  There's no API for users?  The users tables seemed to have changed not at all.  Am I to assume I can just keep what I have if it currently works?

-- sw

[Evert Pot]

Unfortunately there isn't one yet. Everything else has an API because it also has a way for DAV clients to manipulate. Since there's no real DAV standard for managing users, I've also never built an API.

[ste...@niteflyte.net]

On Sunday, January 15, 2017 at 9:25:07 PM UTC-8, Evert Pot wrote:

Unfortunately there isn't one yet. Everything else has an API because it also has a way for DAV clients to manipulate. Since there's no real DAV standard for managing users, I've also never built an API.

I can contribute mine if you like...  you'll have to "Sabre-ize" it; fix all the mistakes; and remove all the assumptions (like I assumed SQLite, always) :-)

My code is designed to be used in a command-line interface as well so there's lots of error-checking with corresponding text messages.  I use Respect\Validation to do most of that stuff (very handy).  All tolled, everything is about 350K.

-- sw

 

[Evert Pot]

What I really really want is a tool exactly like that, but one that can operate via HTTP, remotely.

Ultimately the real API is the HTTP API. Assuming  SQLite (or any SQL) immediately makes it less useful for more advanced users.  A standard tool might also open the door to allowing the tool to be useful for non-sabredav systems (if we make a great standard API specification).

That said, the tool as it is today might still be useful  for some people. Maybe you can just open source it? We can post it from our twitter and put it on the sabre.io blog too.

[Steve Witten]

> On Jan 29, 2017, at 10:19 AM, Evert Pot <ever...@gmail.com> wrote:
>
> What I really really want is a tool exactly like that, but one that can operate via HTTP, remotely.

<snip />

Evert —

First of all, I’m sorry about the late reply. I was traveling without my laptop (it was a pleasure trip so the laptop got a rest for the weekend).

I’m about ready to start an overhaul of this code to replace the database access code that I wrote with some new code that uses the Sabre\PDO objects for calendars and address books. In that process, I can overhaul the user-maintenance code too so that it can operate using HTTP (and retain the CLI that I need). I can copy the Sabre\PDO object code style/structure for the new ‘user’ objects.

I can certainly open source it all but I don’t want to support it except for my own needs. I’m retired and this was basically a hobby project for me (mostly out of frustration with iCloud and ownCloud — both too heavyweight for my needs — and, in the case of my wife’s laptop, it runs macOS ‘Snow Leopard’ so it can’t use iCloud).

An HTTP interface would probably be dependent on the following:

- respect/validation (3.3M of code, 6.7M altogether)
- bcosca/fatfree-core (460K of code, 668K altogether)

You can read more about F3 here: https://fatfreeframework.com/3.6/home. I find it INCREDIBLY USEFUL for doing this kind of stuff.

FYI, the current ‘help’ message for the user maintenance command follows. As you can see, it’s useful but not complicated.

--
==========================================
Steve Witten ste...@niteflyte.net

—— snip, snip

davusr: User maintenance for shared calendars/addressbooks.
Create : davusr create|crt|c {crtopts} [-v|--verbose]
Delete : davusr delete|rm|d {delopts} [-v|--verbose]
Update : davusr update|upd|u {updopts} [-v|--verbose]
List : davusr list|ls|l {lstopts} [-v|--verbose]
Version : davusr version|ver|v
This msg : davusr [help|?|h]
where:
{crtopts} =
-u|--user <uname> : username
-p|--pass <passwd> : password
-e|--email <addr> : email address
-f|--first <fname> : first name
-l|--last <lname> : last name
{delopts} =
-u|--user <uname> : username
{updopts} =
-u|--user <uname> : username
[-p|--pass <passwd>] : new password
[-e|--email <addr> ] : new email address
[-f|--first <fname> ] : new first name
[-l|--last <lname> ] : new last name
{lstopts} =
[-u|--user <uname> ] : username
n.b.
-v|--verbose produces verbose messages.

No argument value may contain embedded whitespace.

[Evert Pot]

Hi Steve,

Well it's pretty cool and let me know when it ends up being open source. Would be curious to take a look. Definitely understandable that you don't want to keep maintaining it. Maintaining open source projects can be quite a time sink ;) (TRUST ME I KNOW)

Cheers,
Evert