Denis Makogon <dmako...@mirantis.com> writes: > Let me elaborate a bit. > > [...] > > Without storing static API contract capabilities gonna be 100% corrupted, > because there's no API description inside Trove.
Im not sure i understand what you mean here. > About reloading, file should not be reloaded, file is a static unmodifiable > template. As the response users sees the combinition of described contract > (from file) and all capabilities inside database table (as i described in > my first emai). To simplify file usage we could deserialize it into dict > object and make it as singleton to use less memory. Im not a fan, at all, of a file based config for this. It will be exposed to users, and can be modeled in the database just fine. > About Kalebs design and whole appoach. Without blocking/allowing certain > capabilities for datastores whole approach is nothing else than "help > document" and this is not acceptable. Incorrect. Its a great first approach. We can use this, and the entries in the db, to conditionally expose things in the extensions. > Approach of capabilities is: "In runtime block/allow tasks to be executed > over certain objects". That why i stand on re-reviewing whole design from > scratch with all contributors. We can do this _using_ kalebs work in the future, when we refactor extensions. Weve had this conversation already, a few months ago when the redis guys first came aboard. re-review is not needed. Kalebs stuff is completely valid, and anything you are talking about can be used by the user facing capabilities. ON A SEPARATE NOTE This is one of the hardest message threads ive ever read. If you guys (everyone on the thread, im talking to you) dont use bottom posting, and quote the sections you are answering, then its nearly impossible to follow. Plz follow the conventions the rest of the OpenStack community uses. So if there is more to discuss, lets continue, using above as a proper way to do it.
pgpWXbIs9UV0C.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev