On Tue, Aug 20, 2013 at 2:58 AM, Yehuda Sadeh <yehuda@xxxxxxxxxxx> wrote:
> Well, practically I'd like to have such work doing baby steps, rather
> than swiping changes. Such changes have higher chances of getting
> completed and eventually merged upstream. That's why I prefer the
> current model of directly linking the plugins (whether statically or
> dynamically), with (relatively) minor internal adjustments.
What current model of "directly linking plugins" do you refer to exactly?
> Maybe start with thinking about the use cases, and then figure what
> kind of api that would be. As I said, I'm not sure that an internal
> api is the way to go, but rather exposing some lower level
> functionality externally. The big difference is that with the former
> we tie in the internal architecture, while the latter hides the [gory]
> details.
The problem is that right now basically everything is 'lower level
functionality', because a lot of generic stuff depends on S3 stuff,
which in turn depends on generic stuff. Take for example the
following;
class RGWHandler_Usage : public RGWHandler_Auth_S3 { }
class RGWHandler_Auth_S3 : public RGWHandler_ObjStore { }
This basically ties usage statistics collection + authentication
handling + object store all together.
I think this needs to be completely unravelled, but before making all
kinds of use cases (like, usage statistics collection or
authentication in this case) it might be wise to know what the design
decisions were to make the S3 API so very much integrated into
everything else. Or is this just legacy?
Roald
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
