You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Oliver Zeigermann <oz...@c1-fse.de> on 2004/07/13 13:25:26 UTC
Re: WebDAV and Notifications
Stefan Lützkendorf wrote:
> 3. Currently Subscriptions are transient. I.e. if the server restarts,
> all subscriptions are lost. So observation of an WebDAV server may be
> incomplete.
> Has anybody thought about makeing subscriptions persitent?
> I think about storing them as resources under a special path
> (configurable, something like /subscriptions). Events catched for the
> subscriptions must be stored too, may be as content of the resource.
Hmmm. What is the use case you have in mind for persistent
subscriptions? I know Daniel had something in mind like clustering,
multiple edit clients that are notified of each other changes, etc. I do
not think they would need persistent subscriptions.
Anyway, what is your idea?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: WebDAV and Notifications
Posted by Oliver Zeigermann <oz...@c1-fse.de>.
Stefan Lützkendorf wrote:
>
> Oliver Zeigermann wrote:
>
>> Stefan Lützkendorf wrote:
>>
>>>
>>> Oliver Zeigermann wrote:
>>>
>>>> Stefan Lützkendorf wrote:
>>>>
>>>>> 3. Currently Subscriptions are transient. I.e. if the server restarts,
>>>>> all subscriptions are lost. So observation of an WebDAV server
>>>>> may be
>>>>> incomplete.
>>>>> Has anybody thought about makeing subscriptions persitent?
>>>>> I think about storing them as resources under a special path
>>>>> (configurable, something like /subscriptions). Events catched for
>>>>> the
>>>>> subscriptions must be stored too, may be as content of the resource.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Hmmm. What is the use case you have in mind for persistent
>>>> subscriptions? I know Daniel had something in mind like clustering,
>>>> multiple edit clients that are notified of each other changes, etc.
>>>> I do not think they would need persistent subscriptions.
>>>>
>>>> Anyway, what is your idea?
>>>
>>>
>>>
>>> I thougth about an application that observes a webdav server, maybe to
>>> index documents, or to keep a workflow system uptodate.
>>> If the webdav server application is restarted, for what reasons ever,
>>> there will be a time where changes on the webdav server are lost,
>>
>>
>>
>> I see. So maybe it should be configurable in a header or wherever if
>> the subscription shall be persistet. Maybe also something like a
>> timeout or time to live for a persistent subscription. Storing it to
>> /subscriptions as an ordinary resource, maybe encoded in XML, sounds
>> like a good idea to me.
>>
>> Do you volunteer to persue this? If so, will it be ready for a beta in
>> early August?
>>
> Early August will be to early, but I'll persue this.
Great! No hurry, keep it fun and let's see how this evolves...
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: WebDAV and Notifications
Posted by Stefan Lützkendorf <lu...@apache.org>.
Oliver Zeigermann wrote:
> Stefan Lützkendorf wrote:
>
>>
>> Oliver Zeigermann wrote:
>>
>>> Stefan Lützkendorf wrote:
>>>
>>>> 3. Currently Subscriptions are transient. I.e. if the server restarts,
>>>> all subscriptions are lost. So observation of an WebDAV server may be
>>>> incomplete.
>>>> Has anybody thought about makeing subscriptions persitent?
>>>> I think about storing them as resources under a special path
>>>> (configurable, something like /subscriptions). Events catched for the
>>>> subscriptions must be stored too, may be as content of the resource.
>>>
>>>
>>>
>>>
>>> Hmmm. What is the use case you have in mind for persistent
>>> subscriptions? I know Daniel had something in mind like clustering,
>>> multiple edit clients that are notified of each other changes, etc. I
>>> do not think they would need persistent subscriptions.
>>>
>>> Anyway, what is your idea?
>>
>>
>> I thougth about an application that observes a webdav server, maybe to
>> index documents, or to keep a workflow system uptodate.
>> If the webdav server application is restarted, for what reasons ever,
>> there will be a time where changes on the webdav server are lost,
>
>
> I see. So maybe it should be configurable in a header or wherever if the
> subscription shall be persistet. Maybe also something like a timeout or
> time to live for a persistent subscription. Storing it to /subscriptions
> as an ordinary resource, maybe encoded in XML, sounds like a good idea
> to me.
>
> Do you volunteer to persue this? If so, will it be ready for a beta in
> early August?
>
Early August will be to early, but I'll persue this.
Regards, Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: WebDAV and Notifications
Posted by Oliver Zeigermann <oz...@c1-fse.de>.
Stefan Lützkendorf wrote:
>
> Oliver Zeigermann wrote:
>
>> Stefan Lützkendorf wrote:
>>
>>> 3. Currently Subscriptions are transient. I.e. if the server restarts,
>>> all subscriptions are lost. So observation of an WebDAV server may be
>>> incomplete.
>>> Has anybody thought about makeing subscriptions persitent?
>>> I think about storing them as resources under a special path
>>> (configurable, something like /subscriptions). Events catched for the
>>> subscriptions must be stored too, may be as content of the resource.
>>
>>
>>
>> Hmmm. What is the use case you have in mind for persistent
>> subscriptions? I know Daniel had something in mind like clustering,
>> multiple edit clients that are notified of each other changes, etc. I
>> do not think they would need persistent subscriptions.
>>
>> Anyway, what is your idea?
>
> I thougth about an application that observes a webdav server, maybe to
> index documents, or to keep a workflow system uptodate.
> If the webdav server application is restarted, for what reasons ever,
> there will be a time where changes on the webdav server are lost,
I see. So maybe it should be configurable in a header or wherever if the
subscription shall be persistet. Maybe also something like a timeout or
time to live for a persistent subscription. Storing it to /subscriptions
as an ordinary resource, maybe encoded in XML, sounds like a good idea
to me.
Do you volunteer to persue this? If so, will it be ready for a beta in
early August?
Cheers,
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: WebDAV and Notifications
Posted by Stefan Lützkendorf <lu...@apache.org>.
Oliver Zeigermann wrote:
> Stefan Lützkendorf wrote:
>
>> 3. Currently Subscriptions are transient. I.e. if the server restarts,
>> all subscriptions are lost. So observation of an WebDAV server may be
>> incomplete.
>> Has anybody thought about makeing subscriptions persitent?
>> I think about storing them as resources under a special path
>> (configurable, something like /subscriptions). Events catched for the
>> subscriptions must be stored too, may be as content of the resource.
>
>
> Hmmm. What is the use case you have in mind for persistent
> subscriptions? I know Daniel had something in mind like clustering,
> multiple edit clients that are notified of each other changes, etc. I do
> not think they would need persistent subscriptions.
>
> Anyway, what is your idea?
I thougth about an application that observes a webdav server, maybe to
index documents, or to keep a workflow system uptodate.
If the webdav server application is restarted, for what reasons ever,
there will be a time where changes on the webdav server are lost,
i.e. the observer is not informed, until it subscribes again.
If subscriptions are persitent, the server knows about them afer restart,
and no interruption of the observation does occur.
May be it is sufficent to have short subscription lifetimes, and
refresh the subscriptions often, so the interuption may be short
enought.
>
> Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
Re: WebDAV and Notifications
Posted by Stefan Lützkendorf <lu...@apache.org>.
Michael Oliver wrote:
> I am starting work on a persistent mechanism for storing the
> subscriptions in xml in a particular path.
Fine!
>
> Then I will be creating (already started) a secondary store to plug into
> our primary XML store to match subscriptions to the uri of the content
> store methods and use those matches to generate am email queue from the
> subscriptions, in another path. Then we have a cron admin daemon that
> will scan that path and pick up and send the messages.
>
> Michael Oliver
> CTO
> Matrix Intermedia Inc.
> 3325 N. Nellis Blvd, #1
> Las Vegas, NV 89115
> Phone:(702)643-7425
> Fax:(520)844-1036
>
> -----Original Message-----
> From: Oliver Zeigermann [mailto:ozeigermann@c1-fse.de]
> Sent: Tuesday, July 13, 2004 4:25 AM
> To: Slide Developers Mailing List
> Subject: Re: WebDAV and Notifications
>
> Stefan Lützkendorf wrote:
>
>>3. Currently Subscriptions are transient. I.e. if the server restarts,
>> all subscriptions are lost. So observation of an WebDAV server may
>
> be
>
>> incomplete.
>> Has anybody thought about makeing subscriptions persitent?
>> I think about storing them as resources under a special path
>> (configurable, something like /subscriptions). Events catched for
>
> the
>
>> subscriptions must be stored too, may be as content of the resource.
>
>
> Hmmm. What is the use case you have in mind for persistent
> subscriptions? I know Daniel had something in mind like clustering,
> multiple edit clients that are notified of each other changes, etc. I do
>
> not think they would need persistent subscriptions.
>
> Anyway, what is your idea?
>
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
RE: WebDAV and Notifications
Posted by Michael Oliver <ol...@matrix-media.com>.
I am starting work on a persistent mechanism for storing the
subscriptions in xml in a particular path.
Then I will be creating (already started) a secondary store to plug into
our primary XML store to match subscriptions to the uri of the content
store methods and use those matches to generate am email queue from the
subscriptions, in another path. Then we have a cron admin daemon that
will scan that path and pick up and send the messages.
Michael Oliver
CTO
Matrix Intermedia Inc.
3325 N. Nellis Blvd, #1
Las Vegas, NV 89115
Phone:(702)643-7425
Fax:(520)844-1036
-----Original Message-----
From: Oliver Zeigermann [mailto:ozeigermann@c1-fse.de]
Sent: Tuesday, July 13, 2004 4:25 AM
To: Slide Developers Mailing List
Subject: Re: WebDAV and Notifications
Stefan Lützkendorf wrote:
> 3. Currently Subscriptions are transient. I.e. if the server restarts,
> all subscriptions are lost. So observation of an WebDAV server may
be
> incomplete.
> Has anybody thought about makeing subscriptions persitent?
> I think about storing them as resources under a special path
> (configurable, something like /subscriptions). Events catched for
the
> subscriptions must be stored too, may be as content of the resource.
Hmmm. What is the use case you have in mind for persistent
subscriptions? I know Daniel had something in mind like clustering,
multiple edit clients that are notified of each other changes, etc. I do
not think they would need persistent subscriptions.
Anyway, what is your idea?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org