[Gluster-devel] HTIME API

[Venky Shankar]

Not exactly.

The idea is to make use of information in the meta file (list of 
journals) so as to not "actively" maintain the backlog. The API would 
return a set of journals (or pathnames) starting from a given timestamp. 
This is similar to history, but used for live changes.

     Venky

On 10/31/2014 11:10 AM, Kotresh Hiremath Ravishankar wrote:
> Hi Venky,
>
> If I understand correctly, the idea is to provide RPC based history API?
> If yes, how can that solve the different clients/consumers having to maintain
> state of how much it has processed?
>
> Thanks and Regards,
> Kotresh H R
>
> ----- Original Message -----
> From: "Venky Shankar" <vshankar at redhat.com>
> To: "Ajeet Jha" <ajha at redhat.com>
> Cc: "Kotresh Hiremath Ravishankar" <khiremat at redhat.com>, gluster-devel at gluster.org
> Sent: Wednesday, October 29, 2014 6:23:40 PM
> Subject: HTIME API
>
> Hey Ajeet,
>
> Since changelog translator maintains a meta file (HTIME) containing a list of consumable changelogs, we could leverage this to provide an API invokable by libgfchangelog (once the interaction is RPC based) to get a list of changelogs for a given time period (similar to what history API does today).
>
> The benefit that this provides is that the consumers[1] need not maintain state (the API takes care of that) of the amount of changelogs [to be] processed and make use of this API to get freshly consumable changelogs.
>
> Thoughts?
>
> [1]: esp for lowlevel API (http://gluster.org/community/documentation/index.php/Features/Gnotify)
>
>      Venky