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@xxxxxxxxxx>
To: "Ajeet Jha" <ajha@xxxxxxxxxx>
Cc: "Kotresh Hiremath Ravishankar" <khiremat@xxxxxxxxxx>, gluster-devel@xxxxxxxxxxx
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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
