mirror of
https://github.com/xcat2/confluent.git
synced 2024-12-25 12:41:39 +00:00
38 lines
1.3 KiB
Plaintext
38 lines
1.3 KiB
Plaintext
Each layer has API implications.
|
|
|
|
For now, I'll start with plugin api.
|
|
Arguments are always passed in keyword style
|
|
|
|
plugins should implement:
|
|
create(nodes, element, configmanager)
|
|
retrieve(nodes, element, configmanager)
|
|
update(nodes, element, configmanager)
|
|
delete(nodes, element, configmanager)
|
|
|
|
For the element '_console/session', the return should be an object
|
|
implementing:
|
|
connect(callback)
|
|
read()
|
|
write(data)
|
|
close()
|
|
|
|
For all other elements for now, the caller should get an iterable.
|
|
This means a plugin may elect to return a tuple, list,
|
|
class of their design implementing the iterator interface,
|
|
or elect to use 'yield' in their function for a generator
|
|
|
|
Northbound of confluent, the interface is straightforward.
|
|
API is presented as a tree of resources.
|
|
|
|
TLS socket resembles the SMASH CLP syntax, but does not actually implement
|
|
SMASH CLP. Notably, client should assume case sensitivity, strings can
|
|
exceed 255 characters, input can be more complex than spec allows,
|
|
and no relationship to CIM is defined. The SMASH CLP prompt -> is used and the
|
|
paradigm of navigating targets like a filesystem is used as well as the
|
|
verb names set, create, start, stop, show, etc.
|
|
|
|
|
|
HTTP presents a mostly RESTful interface (noderange, consoles,
|
|
and optional multi-request, comet behavior)
|
|
|