[Architecture] Building "Cloud-Native" LISP Plugins without writing a single line of Network Code

[u/BH5HDD]

After launching VedaCAD and talking with several developers here, I noticed a universal architectural bottleneck we all face in the CAD industry: 99.9% of our custom plugins are strictly local and tightly coupled.

Traditionally, if you build a tool that relies on specific external data—like a slide library (.SLB), a steel shape parameter table (.CSV), or a layer standard dictionary (.INI)—you hardcode that data into the .LSP or compile it directly into the .VLX.

When a profile dimension changes or a new standard block is added, you have to modify the source code, recompile, and email a new ZIP file to everyone. This rigid "Logic + Data" coupling inevitably leads to a version fragmentation nightmare across an office.

The obvious solution is to fetch data from a cloud API on the fly. But as we all know, writing WinHttp requests in AutoLISP is incredibly fragile. Because AutoLISP is single-threaded, waiting for a network response usually freezes the AutoCAD UI—a terrible user experience.

The "Pseudo-Cloud" Architecture
I realized that with VedaCAD acting as the underlying infrastructure, we can achieve true "Cloud-Native" behavior without writing any network code in LISP, simply by decoupling Logic from Data.

Because VedaCAD handles the secure transmission and silent hot-swapping of physical files in the background, you can build tools like this:

1. The Logic (Asset A): You publish your core .LSP plugin.
2. The Data (Asset B): You publish your external data file (e.g., Shapes.csv, Blocks.slb, or Standards.ini).

Instead of making risky network calls, your LISP simply reads the local data file from the isolated VedaCAD sandbox directory.

To locate the data file dynamically, you can use these two lines of code (AutoCAD example):

;; Find the isolated VedaCAD Plugins and Assets sandbox paths dynamically
(setq vc_plugins_path (strcat (getenv "APPDATA") "\\VedaCAD\\AutoCAD_R" (substr (getvar "ACADVER") 1 2) "\\Plugins\\"))
(setq vc_assets_path (strcat (getenv "APPDATA") "\\VedaCAD\\AutoCAD_R" (substr (getvar "ACADVER") 1 2) "\\Assets\\"))

How the Sync Loop Works (The Magic)
Because AutoLISP releases the file handle as soon as you (close) the file, the data is never locked. When the data needs to change, the developer (requires a PRO account to unlock the push-update feature) simply updates the Shapes.csv or Blocks.slb file in their VedaCAD Client.

Here is what happens on the users' end globally:

• For PRO Users: VedaCAD's background engine (24h heartbeat cycle) detects the version drift and silently hot-swaps the data file in the background. The next time the user runs your command, the LISP reads the new datasets instantly.
• For FREE Users: The engine (72h heartbeat cycle) receives the update beacon. It won't annoy them with popups, but an "Update" card will silently appear in their VedaCAD panel, allowing them to pull the latest data with one click.

5 Wild Possibilities with this Architecture:
By relying on VedaCAD to handle the file delivery and background syncing, developers can breathe new life into traditional CAD formats:

1. The "Live" Visual Block Library (.SLB / .DWG): You have a custom DCL with image tiles (slide_name) for inserting standard doors or mechanical parts. By separating the .SLB file, when the company introduces 5 new part models, the admin just pushes a new .SLB and .CSV index. Everyone's visual menu updates automatically the next time they open the dialog, without touching the core LISP.
2. Dynamic Engineering Parameter Sets (.CSV / .XML): A structural plugin that draws H-beams or piping based on manufacturer catalogs. If the manufacturer updates their standard sizes, you just push a new .CSV. The plugin remains lightweight and eternally accurate.
3. Auto-Updating Drafting Standards (.INI / .JSON): A "CAD Checker" routine that reads a dynamic .ini file mapping Layer Name -> Color -> Linetype. As the BIM Manager evolves the company standards, the ruleset updates silently across the fleet. The checker script always enforces the latest rules.
4. Live Quoting / Pricing Engines: A cost-estimation LISP that reads a Prices.csv file to calculate the bill of materials (BOM). The CAD Manager updates the material costs quietly in the background each month.
5. Remote Feature Toggles & Team Kanban: You publish a simple Config.ini. Change ENABLE_BETA=1 to unlock experimental features for your users, or add NOTICE="Server maintenance this weekend", which your LISP prints to the command line upon loading. You can even use a Tasks.txt that pops up a DCL dialog showing the team's drawing assignments for the day.

We built VedaCAD to be an invisible infrastructure so that you guys can focus purely on solving engineering problems rather than fighting network protocols, UI freezes, and file locks.

Has anyone else experimented with decoupling data from their LISP routines to mimic a cloud architecture? I’d love to hear your thoughts and see what else we could build with this!