User:Mvl/sharing: Difference between revisions

Jump to navigation Jump to search
no edit summary
No edit summary
No edit summary
Line 1: Line 1:
== Overview ==
This idea is inspired by microsoft's [http://msdn.microsoft.com/xml/rss/sse/ Simple Sharing Extensions]. Those extensions allow for easy sharing, and are based on rss.
This idea is inspired by microsoft's [http://msdn.microsoft.com/xml/rss/sse/ Simple Sharing Extensions]. Those extensions allow for easy sharing, and are based on rss.


Line 7: Line 9:
We could try something similar with an ics calendar. I think this could work pretty well. The only problem is that it doesn't scale very well to more users. When there are three users, you need to read the calendars of both the other users. And when there are more users, every users needs to add all the other calendars to its list. This might be solved by some kind of server, but when you need this many users, you are likely better off with caldav.
We could try something similar with an ics calendar. I think this could work pretty well. The only problem is that it doesn't scale very well to more users. When there are three users, you need to read the calendars of both the other users. And when there are more users, every users needs to add all the other calendars to its list. This might be solved by some kind of server, but when you need this many users, you are likely better off with caldav.


== Technical Implementation ==


 
The changelog could be created using x-properties inside the events. The events will also need a version counter.
Technical Implementation


It would make sense to base the implementation on the ics provider. The problem with that would be to add the custom properties (to indicate changes) to the events.
It would make sense to base the implementation on the ics provider. The problem with that would be to add the custom properties (to indicate changes) to the events.


A more advanced solution could be to use the storage calendar as backend (for speed). Then, using an observer, whenever something changes a new ics file can be published, including properties that indicate changes.
A more advanced solution could be to use the storage calendar as backend (for speed). Then, using an observer, whenever something changes a new ics file can be published, including properties that indicate changes.
== Problems ==
The bige problem with this is ofcourse that no other application does this. It's not really interopable.
Confirmed users
503

edits

Navigation menu