Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1210775

Summary:	GFAPI should have a mechanism to receive and return xdata from/to application
Product:	[Community] GlusterFS	Reporter:	Raghavendra Talur <rtalur>
Component:	libgfapi	Assignee:	bugs <bugs>
Status:	CLOSED WONTFIX	QA Contact:	Sudhir D <sdharane>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	mainline	CC:	bugs, ndevos, rtalur, skoduri, srangana
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-01-09 10:13:10 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Raghavendra Talur 2015-04-10 14:23:39 UTC

Description of problem:

An application would greatly benefit if libgfapi could receive and return
xdata.

If this is not acceptable as it makes API not tightly bound, can we define
flags which can be packaged within gfapi as xdata and sent below.

Basically it is a request to allow overloading of all gfapi calls.

Bug https://bugzilla.redhat.com/show_bug.cgi?id=1158621 was raised to add
xdata for syncop and gfapi both.

Closing that bug after adding xdata support to syncop.
This bug will be used for tracking xdata support in gfapi.

Comment 1 Niels de Vos 2016-11-18 14:57:11 UTC

Could you explain a little more about the keys/values that you would like to pass through xdata? Because there is no type-checking in xdata, it is not a very useful API for most users. We should aim to bring real functions and structures to gfapi, not hacky xdata-like approaches.

Also, xdata tends to be a dict_t structure. We can not reasonably expose that to applications. I will need to become a standard array/list of some kind.

Comment 2 Raghavendra Talur 2017-01-09 08:10:07 UTC

This bug was created long back. Now I agree with Niels and would want the API to be extended only when needed and with proper type checking. Having a generic mechanism to pass arbitrary data is dangerous.

Niels,
Please closed this bug.