#825 Persistent Fan Scheme

tactics Wed 18 Nov 2009

As I mentioned before, I am considering developing a web site in Fantom. I have found it would be useful to have a persistent URI scheme. It would be a URI scheme (maybe "pfan://") that would save any objects to the file system under the installation directory. Then, any instance of the Fantom runtime would be able to read, modify, and delete that data.

This would help with two things:

  1. It would allow for simple inter-process communication.
  2. It would make a nice ad-hoc database.

Originally, I ran my server with nohup in the background. To stop it, I had to lookup and kill the process ID. When I got tired of that approach, I had it create an empty sentinel file in the server root, and it would run until that file was deleted. It would be nice to be able to write this instead:

while ((Bool)`pfan:/myServerPod/isRunning`.get)
{
  Actor.sleep(1sec)
}

It would also be super-awesome to be able to forget all about SQL while I'm prototyping. I could use a persistent URI scheme to simply save objects with a URI, stop the server, tweak, compile, restart it, and pull those objects back up.

I'm thinking the objects could simply be stored as their serialized .fob representations in a directory structure mirroring the URI structure. That way, if a class definition is changed or you just want to tweak an object by hand, you can do so with any text editor.

What do you guys think?

brian Wed 18 Nov 2009

I think it is a cool idea, and I have some code that does some similar things.

I think the best way to implement a simple file based database would be to implement a sys::UriSpace, then you could mount it into the fan: namespace. I am not sure you really need a new URI scheme (although that is certainly doable by registering a sys::UriScheme). The advantage of UriSpace over UriScheme, is that a scheme is read-only, it can only resolve objects. UriSpaces have get, create, put, delete.

Then the FileDbUriSpace could just map the CRUD operations to file serialization calls. I would expect the implementation would be pretty light weight.

Something like that might be a good example program actually.

tactics Wed 18 Nov 2009

Yeah. I wasn't sure if it belonged as a scheme or a URI space. I'll try that and see how it works for my application. And then I'll see about throwing together an example app for the docs.

tcolar Wed 18 Nov 2009

Sounds like a cool idea. I think i could make use of this for easy unit testing of my remote system connector (without the remote system).

ivan Thu 19 Nov 2009

While reading this topic I got an idea, probably it should be posted in a separate thread. I really like custom Uri spaces approach and ability to mount them anywhere under fan scheme, but probably it would also be great to have methods put and delete in sys::Uri class. These methods can just refer to corresponding methods of UriScheme. So, if I want, for example, implement a CouchDb support, I can just write CouchDbUriScheme and then use something like this in code:

MyDoc doc := `couchdb://server:port/database/doc:rev`.get
doc.something = newValue
`couchdb://server:port/database/doc:rev`.put(doc)

This looks more straightforward than mounting CouchDbUriScheme to something like fan://mydb and then use UriSpace.root[`/mydb/doc`] and UriSpace.root.put(`/mydob/doc`, mydoc)

Of course, fan:// UriScheme will use all advandages of custom mounted Uri spaces in this case Probably an example with CouchDb is not the best, but I think it illustrates an idea.

brian Thu 19 Nov 2009

but probably it would also be great to have methods put and delete in sys::Uri class.

That is a really interesting concept. Although I think I'd have to see a couple more different UriSpace implementations to get a feel for how it all works. Fantom definitely integrates URI into the platform probably deeper than just about any other language out there. But I'm still not sure we have all the pieces just right yet. BTW a CouchDB Fantom API that really leveraged Fantom's Uri APIs would be a slick project.

Login or Signup to reply.