mirror of https://github.com/rojo-rbx/rojo.git synced 2026-04-20 20:55:50 +00:00

Files

Lucien Greathouse 58b244b7e9 Reorganize some of the unwieldly parts of the codebase

* Moved commands into their own folder to reduce `bin.rs`'s size
* Moved all of the VFS-related functionality into its own folder
* Documented a lot of functions, including a few very obscure ones

2018-01-03 16:45:46 -08:00

1.6 KiB

Raw Blame History

Rojo Design - Protocol Version 1

This is a super rough draft that I'm trying to use to lay out some of my thoughts.

API

POST `/read`

Accepts a Vec<Route> of items to read.

Returns Vec<Option<RbxInstance>>, in the same order as the request.

POST `/write`

Accepts a Vec<{ Route, RbxInstance }> of items to write.

I imagine that the Name attribute of the top-level RbxInstance would be ignored in favor of the route name?

CLI

The rojo serve command uses three major components:

A Virtual Filesystem (VFS), which exposes the filesystem as VfsItem objects
A VFS watcher, which tracks changes to the filesystem and logs them
An HTTP API, which exposes an interface to the Roblox Studio plugin

Transform Plugins

Transform plugins (or filter plugins?) can interject in three places:

Transform a VfsItem that's being read into an RbxInstance in the VFS
Transform an RbxInstance that's being written into a VfsItem in the VFS
Transform a file change into paths that need to be updated in the VFS watcher

The plan is to have several built-in plugins that can be rearranged/configured in project settings:

Base plugin
- Transforms all unhandled files to/from StringValue objects
Script plugin
- Transforms *.lua files to their appropriate file types
JSON/rbxmx/rbxlx model plugin
External binary plugin
- User passes a binary name (like moonc) that modifies file contents

Roblox Studio Plugin

With the protocol version 1 change, the Roblox Studio plugin got a lot simpler. Notably, the plugin doesn't need to be aware of anything about the filesystem's semantics, which is super handy.

1.6 KiB Raw Blame History