diff --git a/documentation/_build/doctrees/anatomy.doctree b/documentation/_build/doctrees/anatomy.doctree index 2a72aeb..104446d 100644 Binary files a/documentation/_build/doctrees/anatomy.doctree and b/documentation/_build/doctrees/anatomy.doctree differ diff --git a/documentation/_build/doctrees/api.doctree b/documentation/_build/doctrees/api.doctree new file mode 100644 index 0000000..e629ad5 Binary files /dev/null and b/documentation/_build/doctrees/api.doctree differ diff --git a/documentation/_build/doctrees/build.doctree b/documentation/_build/doctrees/build.doctree index 1853e38..437fbad 100644 Binary files a/documentation/_build/doctrees/build.doctree and b/documentation/_build/doctrees/build.doctree differ diff --git a/documentation/_build/doctrees/core_restricted.doctree b/documentation/_build/doctrees/core_restricted.doctree index 55537f3..e84586b 100644 Binary files a/documentation/_build/doctrees/core_restricted.doctree and b/documentation/_build/doctrees/core_restricted.doctree differ diff --git a/documentation/_build/doctrees/environment.pickle b/documentation/_build/doctrees/environment.pickle index 3e776e7..707ce2b 100644 Binary files a/documentation/_build/doctrees/environment.pickle and b/documentation/_build/doctrees/environment.pickle differ diff --git a/documentation/_build/doctrees/hooks.doctree b/documentation/_build/doctrees/hooks.doctree index 27dcea6..40190bb 100644 Binary files a/documentation/_build/doctrees/hooks.doctree and b/documentation/_build/doctrees/hooks.doctree differ diff --git a/documentation/_build/doctrees/index.doctree b/documentation/_build/doctrees/index.doctree index 76218cc..1c460c2 100644 Binary files a/documentation/_build/doctrees/index.doctree and b/documentation/_build/doctrees/index.doctree differ diff --git a/documentation/_build/doctrees/plugin_hooks.doctree b/documentation/_build/doctrees/plugin_hooks.doctree new file mode 100644 index 0000000..79fcd56 Binary files /dev/null and b/documentation/_build/doctrees/plugin_hooks.doctree differ diff --git a/documentation/_build/doctrees/plugin_loader.doctree b/documentation/_build/doctrees/plugin_loader.doctree new file mode 100644 index 0000000..493c0d3 Binary files /dev/null and b/documentation/_build/doctrees/plugin_loader.doctree differ diff --git a/documentation/_build/doctrees/project.doctree b/documentation/_build/doctrees/project.doctree index b21c580..5ad9b05 100644 Binary files a/documentation/_build/doctrees/project.doctree and b/documentation/_build/doctrees/project.doctree differ diff --git a/documentation/_build/html/.buildinfo b/documentation/_build/html/.buildinfo index 7db4065..5e8bb2c 100644 --- a/documentation/_build/html/.buildinfo +++ b/documentation/_build/html/.buildinfo @@ -1,4 +1,4 @@ # Sphinx build info version 1 # This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done. -config: d325def9cbc62f774a29b7fa152439a4 +config: aa952c05dc8678fa4bab1d866c89bf40 tags: 645f666f9bcd5a90fca523b33c5a78b7 diff --git a/documentation/_build/html/_sources/anatomy.rst.txt b/documentation/_build/html/_sources/anatomy.rst.txt index cc393f6..4a94f1d 100644 --- a/documentation/_build/html/_sources/anatomy.rst.txt +++ b/documentation/_build/html/_sources/anatomy.rst.txt @@ -1,122 +1,7 @@ .. _anatomy: -=================== -Anatomy of a Plugin -=================== +============== +Plugin Anatomy +============== -Plugins for Plugeth use Golang's `Native Plugin System`_. Plugin modules must export variables using specific names and types. These will be processed by the plugin loader, and invoked at certain points during Geth's operations. - -API -*** - -Flags ------ - -* **Name:** Flags -* **Type:** `flag.FlagSet`_ -* **Behavior:** This FlagSet will be parsed and your plugin will be able to access the resulting flags. Flags will be passed to Geth from the command line and are intended to of the plugin. Note that if any flags are provided, certain checks are disabled within Geth to avoid failing due to unexpected flags. - -Subcommands ------------ - -* **Name:** Subcommands -* **Type:** map[string]func(ctx `*cli.Context`_, args []string) error -* **Behavior:** If Geth is invoked with ``./geth YOUR_COMMAND``, the plugin loader will look for ``YOUR_COMMAND`` within this map, and invoke the corresponding function. This can be useful for certain behaviors like manipulating Geth's database without having to build a separate binary. - -Initialize ----------- - -* **Name:** Initialize -* **Type:** func(*cli.Context, core.PluginLoader, core.logs ) -* **Behavior:** Called as soon as the plugin is loaded, with the cli context and a reference to the plugin loader. This is your plugin's opportunity to initialize required variables as needed. Note that using the context object you can check arguments, and optionally can manipulate arguments if needed for your plugin. -:ref:`Core vs Restricted packages in Plugeth-utils` - -**todo: explain that plugin could provide node.Node with restricted.backend** - -InitializeNode --------------- - -* **Name:** InitializeNode -* **Type:** func(core.Node, core.Backend) -* **Behavior:** This is called as soon as the Geth node is initialized. The core.Node object represents the running node with p2p and RPC capabilities, while the Backend gives you access to a wide array of data you may need to access. - -Tracers -------- - -* **Name:** Tracers -* **Type:** map[string]TracerResult -* **Behavior:** When calling debug.traceX functions (such as ``debug_traceCall`` and ``debug_traceTransaction``) the tracer can be specified as a key to this map and the tracer used will be the TracerResult specified here. TracerResult objects must match the interface: - -.. code-block:: go - - ``// CaptureStart is called at the start of each transaction - CaptureStart(env core.EVM, from core.Address, to core.Address, create bool, input []byte, gas uint64, value *big.Int) {} - // CaptureState is called for each opcode - CaptureState(env core.EVM, pc uint64, op core.OpCode, gas, cost uint64, scope *vm.ScopeContext, rData []byte, depth int, err error) {} - // CaptureFault is called when an error occurs in the EVM - CaptureFault(env core.EVM, pc uint64, op core.OpCode, gas, cost uint64, scope *vm.ScopeContext, depth int, err error) {} - // CaptureEnd is called at the end of each transaction - CaptureEnd(output []byte, gasUsed uint64, t time.Duration, err error) {} - // GetResult should return a JSON serializable result object to respond to the trace call - GetResult() (interface{}, error) {}`` - - -.. warning:: Modifying the values passed into tracer functions can alter the - results of the EVM execution in unpredictable ways. Additonally, some objects may be reused acress calls, so data you wish to capture should be copied rather than retianed by reference. - -LiveTracer ----------- - -* **Name:** LiveTracers -* **Type:** core.Tracer -* **Behavior:** This tracer is used for tracing transactions as they are processed within blocks. Note that if a block does not validate, some transactions may be processed that don't end up in blocks, so be sure to check transactions against finalized blocks. - -The interface for a vm.Tracer is similar to a TracerResult (above), but does not require a ``GetResult()`` function. - -GetAPIs -------- - -* **Name:** GetAPIs -* **Type:** func(core.Node, core.Backend) []rpc.API -* **Behavior:** This allows you to register new RPC methods to run within Geth. - -The GetAPIs function itself will generally be fairly brief, and will looks something like this: - -.. code-block:: go - - ``func GetAPIs(stack *node.Node, backend core.Backend) []core.API { - return []rpc.API{ - { - Namespace: "mynamespace", - Version: "1.0", - Service: &MyService{backend}, - Public: true, - }, - } - }`` - -The bulk of the implementation will be in the ``MyService`` struct. MyService should be a struct with public functions. These functions can have two different types of signatures: - -* RPC Calls: For straight RPC calls, a function should have a ``context.Context`` object as the first argument, followed by an arbitrary number of JSON marshallable arguments, and return either a single JSON marshal object, or a JSON marshallable object and an error. The RPC framework will take care of decoding inputs to this function and encoding outputs, and if the error is non-nil it will serve an error response. - -* Subscriptions: For subscriptions (supported on IPC and websockets), a function should have a ``context.Context`` object as the first argument followed by an arbitrary number of JSON marshallable arguments, and should return an ``*rpc.Subscription`` object. The subscription object can be created with ``rpcSub := notifier.CreateSubscription()``, and JSON marshallable data can be sent to the subscriber with ``notifier.Notify(rpcSub.ID, b)``. - -A very simple MyService might look like: - -.. code-block:: go - - ``type MyService struct{} - - func (h MyService) HelloWorld(ctx context.Context) string { - return "Hello World" - }`` - -And the client could access this with an rpc call to -``mynamespace_helloworld`` - - - - -.. _*cli.Context: https://pkg.go.dev/github.com/urfave/cli#Context -.. _flag.FlagSet: https://pkg.go.dev/flag#FlagSet -.. _Native Plugin System: https://pkg.go.dev/plugin \ No newline at end of file +.. todo:: fill in disections of archetypal plugins \ No newline at end of file diff --git a/documentation/_build/html/_sources/api.rst.txt b/documentation/_build/html/_sources/api.rst.txt new file mode 100644 index 0000000..ef3ee53 --- /dev/null +++ b/documentation/_build/html/_sources/api.rst.txt @@ -0,0 +1,120 @@ +.. _api: + +=== +API +=== + +Plugins for Plugeth use Golang's `Native Plugin System`_. Plugin modules must export variables using specific names and types. These will be processed by the plugin loader, and invoked at certain points during Geth's operations. + +Flags +----- + +* **Name:** Flags +* **Type:** `flag.FlagSet`_ +* **Behavior:** This FlagSet will be parsed and your plugin will be able to access the resulting flags. Flags will be passed to Geth from the command line and are intended to of the plugin. Note that if any flags are provided, certain checks are disabled within Geth to avoid failing due to unexpected flags. + +Subcommands +----------- + +* **Name:** Subcommands +* **Type:** map[string]func(ctx `*cli.Context`_, args []string) error +* **Behavior:** If Geth is invoked with ``./geth YOUR_COMMAND``, the plugin loader will look for ``YOUR_COMMAND`` within this map, and invoke the corresponding function. This can be useful for certain behaviors like manipulating Geth's database without having to build a separate binary. + +Initialize +---------- + +* **Name:** Initialize +* **Type:** func(*cli.Context, core.PluginLoader, core.logs ) +* **Behavior:** Called as soon as the plugin is loaded, with the cli context and a reference to the plugin loader. This is your plugin's opportunity to initialize required variables as needed. Note that using the context object you can check arguments, and optionally can manipulate arguments if needed for your plugin. + +.. todo:: explain that plugin could provide node.Node with + restricted.backend + +InitializeNode +-------------- + +* **Name:** InitializeNode +* **Type:** func(core.Node, core.Backend) +* **Behavior:** This is called as soon as the Geth node is initialized. The core.Node object represents the running node with p2p and RPC capabilities, while the Backend gives you access to a wide array of data you may need to access. + +Tracers +------- + +* **Name:** Tracers +* **Type:** map[string]TracerResult +* **Behavior:** When calling debug.traceX functions (such as ``debug_traceCall`` and ``debug_traceTransaction``) the tracer can be specified as a key to this map and the tracer used will be the TracerResult specified here. TracerResult objects must match the interface: + +.. code-block:: go + + ``// CaptureStart is called at the start of each transaction + CaptureStart(env core.EVM, from core.Address, to core.Address, create bool, input []byte, gas uint64, value *big.Int) {} + // CaptureState is called for each opcode + CaptureState(env core.EVM, pc uint64, op core.OpCode, gas, cost uint64, scope *vm.ScopeContext, rData []byte, depth int, err error) {} + // CaptureFault is called when an error occurs in the EVM + CaptureFault(env core.EVM, pc uint64, op core.OpCode, gas, cost uint64, scope *vm.ScopeContext, depth int, err error) {} + // CaptureEnd is called at the end of each transaction + CaptureEnd(output []byte, gasUsed uint64, t time.Duration, err error) {} + // GetResult should return a JSON serializable result object to respond to the trace call + GetResult() (interface{}, error) {}`` + + +.. warning:: Modifying the values passed into tracer functions can + alter the + results of the EVM execution in unpredictable ways. Additonally, some objects may be reused acress calls, so data you wish to capture should be copied rather than retianed by reference. + +LiveTracer +---------- + +* **Name:** LiveTracers +* **Type:** core.Tracer +* **Behavior:** This tracer is used for tracing transactions as they are processed within blocks. Note that if a block does not validate, some transactions may be processed that don't end up in blocks, so be sure to check transactions against finalized blocks. + +The interface for a vm.Tracer is similar to a TracerResult (above), but does not require a ``GetResult()`` function. + +GetAPIs +------- + +* **Name:** GetAPIs +* **Type:** func(core.Node, core.Backend) []rpc.API +* **Behavior:** This allows you to register new RPC methods to run within Geth. + +The GetAPIs function itself will generally be fairly brief, and will looks something like this: + +.. code-block:: go + + ``func GetAPIs(stack *node.Node, backend core.Backend) []core.API { + return []rpc.API{ + { + Namespace: "mynamespace", + Version: "1.0", + Service: &MyService{backend}, + Public: true, + }, + } + }`` + +The bulk of the implementation will be in the ``MyService`` struct. MyService should be a struct with public functions. These functions can have two different types of signatures: + +* RPC Calls: For straight RPC calls, a function should have a ``context.Context`` object as the first argument, followed by an arbitrary number of JSON marshallable arguments, and return either a single JSON marshal object, or a JSON marshallable object and an error. The RPC framework will take care of decoding inputs to this function and encoding outputs, and if the error is non-nil it will serve an error response. + +* Subscriptions: For subscriptions (supported on IPC and websockets), a function should have a ``context.Context`` object as the first argument followed by an arbitrary number of JSON marshallable arguments, and should return an ``*rpc.Subscription`` object. The subscription object can be created with ``rpcSub := notifier.CreateSubscription()``, and JSON marshallable data can be sent to the subscriber with ``notifier.Notify(rpcSub.ID, b)``. + +A very simple MyService might look like: + +.. code-block:: go + + ``type MyService struct{} + + func (h MyService) HelloWorld(ctx context.Context) string { + return "Hello World" + }`` + +And the client could access this with an rpc call to +``mynamespace_helloworld`` + + + + +.. _*cli.Context: https://pkg.go.dev/github.com/urfave/cli#Context +.. _flag.FlagSet: https://pkg.go.dev/flag#FlagSet +.. _Native Plugin System: https://pkg.go.dev/plugin \ No newline at end of file diff --git a/documentation/_build/html/_sources/build.rst.txt b/documentation/_build/html/_sources/build.rst.txt index e81b8b7..28d302b 100644 --- a/documentation/_build/html/_sources/build.rst.txt +++ b/documentation/_build/html/_sources/build.rst.txt @@ -1,7 +1,8 @@ .. _build: -Build -===== +================ +Build and Deploy +================ .. contents:: :local: diff --git a/documentation/_build/html/_sources/core_restricted.rst.txt b/documentation/_build/html/_sources/core_restricted.rst.txt index 433318f..c224faf 100644 --- a/documentation/_build/html/_sources/core_restricted.rst.txt +++ b/documentation/_build/html/_sources/core_restricted.rst.txt @@ -4,4 +4,5 @@ Core vs Restricted packages in Plugeth-utils ============================================ -**todo: copy on core and restricted packages in utils. what, why, how.** + +.. todo:: need explinations of core vs restircted functionality. what, why, how. \ No newline at end of file diff --git a/documentation/_build/html/_sources/hooks.rst.txt b/documentation/_build/html/_sources/hooks.rst.txt index 397c22c..b7940ee 100644 --- a/documentation/_build/html/_sources/hooks.rst.txt +++ b/documentation/_build/html/_sources/hooks.rst.txt @@ -4,5 +4,4 @@ Plugin Hooks ============ - -**todo: discussion on plugin hooks** \ No newline at end of file +.. todo:: discussion of plugin hooks diff --git a/documentation/_build/html/_sources/index.rst.txt b/documentation/_build/html/_sources/index.rst.txt index f3ff255..ab2fd8a 100644 --- a/documentation/_build/html/_sources/index.rst.txt +++ b/documentation/_build/html/_sources/index.rst.txt @@ -8,11 +8,12 @@ PluGeth PluGeth is a fork of the `Go Ethereum Client Geth`_ that implements a plugin architecture, allowing developers to extend Geth's capabilities in a number of different ways using plugins, rather than having to create additional, new forks of Geth. -**WARNING: UNSTABLE API** +.. warning:: Right now PluGeth is in early development. We are + still settling on some of the plugin APIs, and are + not yet making official releases. From an operational + perspective, PluGeth should be as stable as upstream Geth less whatever isstability is added by plugins you might run. But if you plan to run PluGeth today, be aware that furture updates will likely break you plugins. -Right now PluGeth is in early development. We are still settling on some of the plugin APIs, and are not yet making official releases. From an operational perspective, PluGeth should be as stable as upstream Geth less whatever instability is added by plugins you might run. But if you plan to run PluGeth today, be aware that future updates will likely break your plugins. - Table of Contents ***************** @@ -26,6 +27,7 @@ Table of Contents types hooks anatomy + .. toctree:: :maxdepth: 1 @@ -37,8 +39,11 @@ Table of Contents :maxdepth: 1 :caption: Reference - sytem_req + system_req + plugin_loader + plugin_hooks core_restricted + api .. toctree:: :maxdepth: 1 diff --git a/documentation/_build/html/_sources/plugin_hooks.rst.txt b/documentation/_build/html/_sources/plugin_hooks.rst.txt new file mode 100644 index 0000000..601ee4a --- /dev/null +++ b/documentation/_build/html/_sources/plugin_hooks.rst.txt @@ -0,0 +1,7 @@ +.. _plugin_hooks: + +============ +Plugin Hooks +============ + +.. todo:: guide to writing plugin hooks \ No newline at end of file diff --git a/documentation/_build/html/_sources/plugin_loader.rst.txt b/documentation/_build/html/_sources/plugin_loader.rst.txt new file mode 100644 index 0000000..d1de719 --- /dev/null +++ b/documentation/_build/html/_sources/plugin_loader.rst.txt @@ -0,0 +1,7 @@ +.. _plugin_loader: + +============= +Plugin Loader +============= + +.. todo:: breakdown of plugin loader function \ No newline at end of file diff --git a/documentation/_build/html/_sources/project.rst.txt b/documentation/_build/html/_sources/project.rst.txt index 76d3919..315f726 100644 --- a/documentation/_build/html/_sources/project.rst.txt +++ b/documentation/_build/html/_sources/project.rst.txt @@ -37,14 +37,14 @@ Plugins are packages which contain premade plugins as well as a location provide Dependency Scheme ----------------- -**todo: copy on version number protocol** +.. todo:: needs elaboration of dependency scheme -.. _obscures security updates as optimixations: https://blog.openrelay.xyz/vulnerability-lifecycle-framework-geth/ +.. _obscures security updates as optimizations: https://blog.openrelay.xyz/vulnerability-lifecycle-framework-geth/ .. _PluGeth: https://github.com/openrelayxyz/plugeth .. _PluGeth-Utils: https://github.com/openrelayxyz/plugeth-utils .. _PluGeth-Plugins: https://github.com/openrelayxyz/plugeth-plugin \ No newline at end of file diff --git a/documentation/_build/html/anatomy.html b/documentation/_build/html/anatomy.html index ad59631..371a82a 100644 --- a/documentation/_build/html/anatomy.html +++ b/documentation/_build/html/anatomy.html @@ -3,7 +3,7 @@ - Anatomy of a Plugin — Plugeth Austin Roberts documentation + Plugin Anatomy — Plugeth Austin Roberts documentation + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

API

+

Plugins for Plugeth use Golang’s Native Plugin System. Plugin modules must export variables using specific names and types. These will be processed by the plugin loader, and invoked at certain points during Geth’s operations.

+
+

Flags

+
    +
  • Name: Flags

  • +
  • Type: flag.FlagSet

  • +
  • Behavior: This FlagSet will be parsed and your plugin will be able to access the resulting flags. Flags will be passed to Geth from the command line and are intended to of the plugin. Note that if any flags are provided, certain checks are disabled within Geth to avoid failing due to unexpected flags.

  • +
+
+
+

Subcommands

+
    +
  • Name: Subcommands

  • +
  • Type: map[string]func(ctx *cli.Context, args []string) error

  • +
  • Behavior: If Geth is invoked with ./geth YOUR_COMMAND, the plugin loader will look for YOUR_COMMAND within this map, and invoke the corresponding function. This can be useful for certain behaviors like manipulating Geth’s database without having to build a separate binary.

  • +
+
+
+

Initialize

+
    +
  • Name: Initialize

  • +
  • Type: func(*cli.Context, core.PluginLoader, core.logs )

  • +
  • Behavior: Called as soon as the plugin is loaded, with the cli context and a reference to the plugin loader. This is your plugin’s opportunity to initialize required variables as needed. Note that using the context object you can check arguments, and optionally can manipulate arguments if needed for your plugin.

  • +
+
+

Todo

+

explain that plugin could provide node.Node with +restricted.backend

+
+
+
+

InitializeNode

+
    +
  • Name: InitializeNode

  • +
  • Type: func(core.Node, core.Backend)

  • +
  • Behavior: This is called as soon as the Geth node is initialized. The core.Node object represents the running node with p2p and RPC capabilities, while the Backend gives you access to a wide array of data you may need to access.

  • +
+
+
+

Tracers

+
    +
  • Name: Tracers

  • +
  • Type: map[string]TracerResult

  • +
  • Behavior: When calling debug.traceX functions (such as debug_traceCall and debug_traceTransaction) the tracer can be specified as a key to this map and the tracer used will be the TracerResult specified here. TracerResult objects must match the interface:

  • +
+
``// CaptureStart is called at the start of each transaction
+CaptureStart(env core.EVM, from core.Address, to core.Address, create bool, input []byte, gas uint64, value *big.Int) {}
+// CaptureState is called for each opcode
+CaptureState(env core.EVM, pc uint64, op core.OpCode, gas, cost uint64, scope *vm.ScopeContext, rData []byte, depth int, err error) {}
+// CaptureFault is called when an error occurs in the EVM
+CaptureFault(env core.EVM, pc uint64, op core.OpCode, gas, cost uint64, scope *vm.ScopeContext, depth int, err error) {}
+// CaptureEnd is called at the end of each transaction
+CaptureEnd(output []byte, gasUsed uint64, t time.Duration, err error) {}
+// GetResult should return a JSON serializable result object to respond to the trace call
+GetResult() (interface{}, error) {}``
+
+
+
+

Warning

+

Modifying the values passed into tracer functions can +alter the +results of the EVM execution in unpredictable ways. Additonally, some objects may be reused acress calls, so data you wish to capture should be copied rather than retianed by reference.

+
+
+
+

LiveTracer

+
    +
  • Name: LiveTracers

  • +
  • Type: core.Tracer

  • +
  • Behavior: This tracer is used for tracing transactions as they are processed within blocks. Note that if a block does not validate, some transactions may be processed that don’t end up in blocks, so be sure to check transactions against finalized blocks.

  • +
+

The interface for a vm.Tracer is similar to a TracerResult (above), but does not require a GetResult() function.

+
+
+

GetAPIs

+
    +
  • Name: GetAPIs

  • +
  • Type: func(core.Node, core.Backend) []rpc.API

  • +
  • Behavior: This allows you to register new RPC methods to run within Geth.

  • +
+

The GetAPIs function itself will generally be fairly brief, and will looks something like this:

+
  ``func GetAPIs(stack *node.Node, backend core.Backend) []core.API {
+  return []rpc.API{
+   {
+     Namespace: "mynamespace",
+     Version:      "1.0",
+     Service:      &MyService{backend},
+     Public:              true,
+   },
+  }
+}``
+
+
+

The bulk of the implementation will be in the MyService struct. MyService should be a struct with public functions. These functions can have two different types of signatures:

+
    +
  • RPC Calls: For straight RPC calls, a function should have a context.Context object as the first argument, followed by an arbitrary number of JSON marshallable arguments, and return either a single JSON marshal object, or a JSON marshallable object and an error. The RPC framework will take care of decoding inputs to this function and encoding outputs, and if the error is non-nil it will serve an error response.

  • +
  • Subscriptions: For subscriptions (supported on IPC and websockets), a function should have a context.Context object as the first argument followed by an arbitrary number of JSON marshallable arguments, and should return an *rpc.Subscription object. The subscription object can be created with rpcSub := notifier.CreateSubscription(), and JSON marshallable data can be sent to the subscriber with notifier.Notify(rpcSub.ID, b).

  • +
+

A very simple MyService might look like:

+
``type MyService struct{}
+
+  func (h MyService) HelloWorld(ctx context.Context) string {
+    return "Hello World"
+  }``
+
+
+

And the client could access this with an rpc call to +mynamespace_helloworld

+
+
+ + +
+
+ +
+
+
+
+ + + + \ No newline at end of file diff --git a/documentation/_build/html/build.html b/documentation/_build/html/build.html index 139d3e7..a905eb8 100644 --- a/documentation/_build/html/build.html +++ b/documentation/_build/html/build.html @@ -3,7 +3,7 @@ - Build — Plugeth Austin Roberts documentation + Build and Deploy — Plugeth Austin Roberts documentation + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

Plugin Hooks

+
+

Todo

+

guide to writing plugin hooks

+
+
+ + +
+
+ +
+
+
+
+ + + + \ No newline at end of file diff --git a/documentation/_build/html/plugin_loader.html b/documentation/_build/html/plugin_loader.html new file mode 100644 index 0000000..9e35e0e --- /dev/null +++ b/documentation/_build/html/plugin_loader.html @@ -0,0 +1,124 @@ + + + + + + Plugin Loader — Plugeth Austin Roberts documentation + + + + + + + + + + + + + + +
+ + +
+ +
+
+
+ +
+
+
+
+ +
+

Plugin Loader

+
+

Todo

+

breakdown of plugin loader function

+
+
+ + +
+
+ +
+
+
+
+ + + + \ No newline at end of file diff --git a/documentation/_build/html/plugins.html b/documentation/_build/html/plugins.html index 0c9f7ef..63f01a4 100644 --- a/documentation/_build/html/plugins.html +++ b/documentation/_build/html/plugins.html @@ -37,15 +37,19 @@
  • Project Design
  • Basic Types of Plugins
  • Plugin Hooks
  • -
  • Anatomy of a Plugin
  • +
  • Plugin Anatomy
  • Tutorials

    Reference

    Contact

    Tutorials

    Reference

    Contact

    Tutorials

    Reference

    Contact

    Tutorials

    Reference

    -

    Tutorials

    Reference

    Contact

    Tutorials

    Reference

    Contact