Home » Archived » Eclipse SmartHome » CalDAV ESH(or OH2) binding(Poll for ideas + Changes to be made in the core)
| CalDAV ESH(or OH2) binding [message #1717052] |
Wed, 09 December 2015 18:01  |
 Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Hi all,
I have studied the existing gcal and caldav OH1 bindings. Whilst they have/had their merits, they are not really adapted to the ESH world of things. I would give this part a bit of a development push, but before embarking into something I would like to poll for your ideas
1. The current gcal binding is a bit in trouble as google has changed their API recently. As usual, Google's API is clean and clear, based on OAuth 2.0, which is a bit of tinkering in terms of configuration
2. The CalDAV binding has a bit of a 'forced' architecture, with a separate .io binding mainly because of the two different bindings that make use of it, each with their own use case. I presume it was crafted this way because of convenience reasons, not per se re-usability as a .io binding. This binding uses a few external libs, one is Sardine (WebDAV client , Apache 2.0 lic.), and ical4j (iCal data format handling, license is something home-brewed)
Both these bindings define calendar events that send command or post updates to Items.
Luckily, Google does support CalDAV/iCal, so my idea would be to code a new CalDAV binding that would be able to support Google Calendar, and in my case, also Apple's iCloud. I would also investigate how that binding could tie into the upcoming Notification infrastructure.
Question 1: the core provides a ItemChannelLinkRegistry (or ItemThingLinkRegistry), but all queries are made from the Item towards the Channel or Thing. You can query all the Channels linked to an Item, but not the Items linked to a Channel. This was possible with a soon to be depreciated API in Channel. Is there a specific reason why these complementary API were not added to the LinkRegistry classes? Will they be, or do we need a ChannelItemLinkRegistry instead... ?
Question 2: the current bindings act upon Items, whereas in the ESH world, the interface to Handlers is via Channels. So, do we rather want to define calendar events that do stuff on channels, or do we stick with the (more user-friendly?) Item approach? if the latter, then Question 1 is of relevance.
Question 3: would "calendar" Things be the most logical route here? or should the Calendar be a Bridge for "event" Things? And in either case, what Channels would be defined on these Things?
Question 4: would we create Channels dynamically, based on the information found in the calendar event? e.g. you define some channel to be updated in an event, if not existing, it will be created in the calendar Thing, and could be reference by Items that you want to act upon and so forth
Karel
|
|
| |
| Re: CalDAV ESH(or OH2) binding [message #1717264 is a reply to message #1717199] |
Fri, 11 December 2015 08:45  |
Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
tx Simon
I think the use cases would be the same as for the OH1 versions:
- trigger updates and commands to [channels][items] by using a pre-defined text format in the body of the event
- record Events (most probably, StateEvents) to a calendar, for future replay (e.g. presence simulation)
- read out all the fields (name, location, start time,....) of calendar events, so that Rules can do something meaningful with it (for example: having an event in the calendar with "Home" as the title, or location, could be an indicator for a Rule that some sort of presence is set)
In this constellation, should the calendar be a Thing (with for example, other kinds of WebDAV resources for sibling Things (to-do lists,...))
. Or rather a Bridge, with calendar events being separate Things?
|
|
|
| Re: CalDAV ESH(or OH2) binding [message #1717466 is a reply to message #1717264] |
Mon, 14 December 2015 08:57 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Quote:
should the calendar be a Thing (with for example, other kinds of WebDAV resources for sibling Things (to-do lists,...))
. Or rather a Bridge, with calendar events being separate Things?
I'm not sure I can get my head around how this would work..... Neither makes sense to me, but I've not used the OH1 binding...
Quote:
what are the use-cases that the CalDAV binding should cover?
Personally, I would like to see the concept of a schedule added to ESH, so that we can schedule rules (or possibly single 'item commands') directly into an internal scheduler. WebDAV would then (in my mind at least) just provide a mechanism for scheduling/transferring such schedules - providing the user a way to interact with the schedule (or more correctly, the users UI).
I thought that such a concept was planned already, and to me at least (having not used the OH1 WebDAV binding) it makes more sense than trying to create new things or items from events (which I think is what you're proposing?), but to link this in to the rules system.
Ideally, I would be interested in WebDAV/CalDAV being used as the protocol for an ESH REST interface to manipulate such an internal ESH scheduler, such that a UI could directly interact with the schedule, and also to allow it to read from external WebDAV servers (eg Google) to pull in events from other sources.
Chris
|
|
|
| Re: CalDAV ESH(or OH2) binding [message #1717500 is a reply to message #1717466] |
Mon, 14 December 2015 12:00 |
Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Chris Jackson wrote on Mon, 14 December 2015 03:57
Personally, I would like to see the concept of a schedule added to ESH, so that we can schedule rules (or possibly single 'item commands') directly into an internal scheduler. WebDAV would then (in my mind at least) just provide a mechanism for scheduling/transferring such schedules - providing the user a way to interact with the schedule (or more correctly, the users UI).
Indeed, that would make a lot of sense. In fact, the rule scheduling today uses Quartz for scheduling. If we keep it that way, then it is just a question of exposing what is in the Quartz scheduler to CalDAV binding, or even the REST interface.
Quote:I thought that such a concept was planned already, and to me at least (having not used the OH1 WebDAV binding) it makes more sense than trying to create new things or items from events (which I think is what you're proposing?), but to link this in to the rules system.
mmh.. creating things or items I did not have in mind personally, it was more about sending events (e.g. Commands or Updates) to them.
Quote:Ideally, I would be interested in WebDAV/CalDAV being used as the protocol for an ESH REST interface to manipulate such an internal ESH scheduler, such that a UI could directly interact with the schedule, and also to allow it to read from external WebDAV servers (eg Google) to pull in events from other sources.
er... not sure I fully understand here. You would have the UI go via REST, an another part of the UI "speak" WebDAV/CalDAV to the OH server (eg. OH exposing the internal scheduler as a WebDAV resource, that can be accessed by any kind of client), or, issue WebDAV-"like" commands via REST points?
We are in fact mixing two thing here,e.g .OH as a WebDav Client, and OH as a WebDav server, no?
There are many scenarios possible:
1. OH CalDAV binding, acting as CalDAV client to an external CalDAV server
2. OH "Scheduler", being exposed as a CalDAV resource
3. OH "Scheduler, acting as a CalDAV client, exposing its internal scheduler on a CalDAV server
...
Karel
|
|
|
| Re: CalDAV ESH(or OH2) binding [message #1717505 is a reply to message #1717500] |
Mon, 14 December 2015 12:48 |
Chris Jackson
Messages: 256
Registered: December 2013 |
Senior Member |
|
|
Quote:
or, issue WebDAV-"like" commands via REST points?
Yes - something like this. I'm not 100% sure of the detail at the moment. I looked at this for OH2/HABmin a few months back with a view of producing a scheduler interface. It made sense to use an existing protocol, and WebDAV, or some derivative, seemed a good idea. There are many ways to play the game of course - I found a draft RFC that is WebDAV over JSON which would be good I think (although I can't find it again now!). It is basically just WebDAV, but taking each WebDAV line/field and putting it into a JSON field. Basically, I was trying to avoid defining my own protocol and use something that is at least reasonably standard...
Quote:
We are in fact mixing two thing here,e.g .OH as a WebDav Client, and OH as a WebDav server, no?
Yes - sorry, I've mixed both things into the same discussion - they are different, but related (at least I think so).
I assume that the current WebDAV / GoogleCal reads the events from a server, stores them locally until execution, and then executes them at the given time? So, arguably we already have 2 out of 3 parts - the CalDEV client and the scheduler - we 'just' need to expose the schedule as a WebDAV-like server (via REST/JSON).... Implementation can of course be split into 3 parts as you have - I'm really just talking functionality at the moment 
|
|
|
| Re: CalDAV ESH(or OH2) binding [message #1717540 is a reply to message #1717505] |
Mon, 14 December 2015 15:47 |
Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Quote:I assume that the current WebDAV / GoogleCal reads the events from a server, stores them locally until execution, and then executes them at the given time? So, arguably we already have 2 out of 3 parts - the CalDEV client and the scheduler - we 'just' need to expose the schedule as a WebDAV-like server (via REST/JSON).... Implementation can of course be split into 3 parts as you have - I'm really just talking functionality at the moment
Well, sort of, but not quite  It reads from the server at specific intervals, and stores them in a cache (which, in turn is file-based using the iCal format), but on the other hand the events are scheduled immediately using Quartz.
I just had a quick peek at the Quartz API, and you can query the quartz scheduler for scheduled jobs, determine the next execution time and so forth. If we are wise in terms of choosing names for Quartz trigger and/or jobs, we can use the quartz scheduler itself to store jobs (and then piggy-back on the storage facilities of quartz, as it supports different persistent storages, so that it survives restarts of the runtime). If that would not work, I would use the mapDB Storage interface already defined in the ESH core.
The question that remains for me is whether you want to have OH act as a CalDAV server, or whether it should be a client that stores all the calendar events externally? the former would be cool, allowing any client to control the scheduling in the core. The latter is easier in terms of calendar management, e.g. controlling who accesses the agenda, sharing it with others, have it in the cloud and so forth (e.g. Google Calendar, or iCloud for example).
Of course, in your scenario of feeding Web/CalDAV like commands over REST to the Core, you would either serve the resource, or have to build a bridge between the REST piece and a WebDAV client that fetches stuff remotely.
Karel
|
|
| | |
| Re: CalDAV ESH(or OH2) binding [message #1718067 is a reply to message #1718033] |
Fri, 18 December 2015 20:42 |
Karel Goderis
Messages: 198
Registered: March 2014 |
Senior Member |
|
|
Kai Kreuzer wrote on Fri, 18 December 2015 11:24
I agree with Simon and Chris: The use case is nothing that should be done as a binding as modelling it as a thing with channels does not really fit here. Most of what you state sounds as if it mostly a rule trigger (we can implement nice trigger module handlers for the new rule engine - btw. the very first being the CRON trigger, which uses Quartz). Additionally, it could potentially also be a source for the notification mechanism (I know, you are waiting for feedback on that PR since a long time as well...).
After an initial study round on the subject, including all the WebDAV server stuff, I agree that we can better skip the binding route for this, and internalise the WebDAV functionality, and expose the scheduler through CalDAV.
In fact, if you make it an EventSubscriber, you can use it to record events into the calendar. And in the other direction, you generate triggers from the calendar event data that tie into the new automation code. (as most of the time, it sounds easy )
Quote:Wrt WebDAV software: As discussed in private, Milton.io is not an option - only the community edition would be ok, which is afaik only a WebDAV client. If we don't want to do the server part (and I think this might actually be a bit far off from the scope of ESH), this should be fine, though.
The CE is also a WebDAV server. In fact, after studying the caldav code of this webdav library, I came to the conclusion that the CE part (e.g. WebDAV) of the library is already doing all the heavy lifting, and the CalDAV part is rather thin extension of the base library. But the problem is that there are not a 1000 ways to implement the same RFC on top of that CE library, and thus, it is going to be shitty with respect to an IP sign-off. On the other hand, there is no other good WebDAV server java library available
K
|
|
| | | | |
Goto Forum:
Current Time: Thu Sep 19 21:14:10 GMT 2024
Powered by FUDForum. Page generated in 0.04680 seconds |
] 
Search
Help
Register
Login
Home
