[Sputnik-list] versium (was blueprint)

[pierre pracht]

Le 12 févr. 08 à 11:35, Yuri Takhteyev a écrit :

>> Functionality of CouchDB table/view storage is orthogonal to versium
>> document storage.
>
> Well, it's a similar idea.  The main differences are:
>
> 1. Versium is an API while CouchDB and Amazon SimpleDB are
> implementations.

Yes, I always intended to speak of Versium as an API.

> Versium's "simple" storage is like a baby version
> of CouchDB.

No No No
CouchDB make much more than get and set by key, it's just resource  
handling in a REST fashion.
http://www.couchdbwiki.com/index.php?title=CouchDb_Quick_Overview

What offer CouchDB is the view feature :
>> Query-able and index-able, featuring a table oriented reporting  
>> engine that uses Javascript as a query language.


Versium is for me a document (plain resource) storage.
You make a confusion  :
  - On search (full-text search vs column indexing)
	More on this later
  - On versioning (document versioning vs eventual consistency)
	http://en.wikipedia.org/wiki/Eventual_consistency
	CouchDB use versioning but isn't intended to offer versioning

> There is no reason why one can't make a Versium plugin
> for CouchDB / S3, since they align quite well conceptually.

If CouchDB implement document attachment (plain resource).
You will be able to build a plugin for it :
   - put meta-data in object (record / structured resource)
     - author
     - comment
     - version of document (document as file / plain resource)
	** not the same as record version of CouchDB **
   - let CouchDB put file in an additional storage
    	In fact this additional storage would be a Versium !!

> Whether this is worth the effort is a different question.

S3 is a perfect fit for an extension of storage.simple
Swap _open_file, _write_file by conn.put, conn.get and your done.

Worth the effort ?
You put have a screen-cast on your blog to promote your shiny new  
framework :)

Joke aside, I mean : Versium = S3 + versionning (in usage not api)

> 2. Versium doesn't support search - yet.

Here come the turning point :
Does Versium need to implement search ?

If you have an other storage API, let's call it Metasium.
You would write a Versium.decorator build on a Versium.storage and a  
Metasium.storage.
(rq: Versium.decorator Versium.storage having same interfaces)

When you store a document in Versium.decorator it scan document for  
word and store (word,document_id) tuple

To make a search you query Metasium.storage.

> 3. Versium has the concept of versioning built in.  I don't think
> S3/SimpleDB/CouchDB do that, but it wouldn't be hard to simulate.

See above.

>> So if you add an indexed meta-data storage (table/view) ?
>>  - not tied to SQL schema
>>  - With swappable back-end : SimpleDB, CouchDB, SQL, lua table + file
>
> We'll it's a matter of writing them.

Not exactly, I try to sell :
  - Freeze Versium
  - Take a look at a tuple storage for meta-data

Rq: For architecture consideration, Versium would lost author comment  
extra
And in mean time, Some Versium.storage whould implement a  
Metasium.storage

Disclaimer : Metasium google on nothing, juste a joke on Versium.

> At this point I don't have the
> time to do that myself, so my plan is to focus on maintaining the
> "simple" backend.

I didn't ask for some code, what I try, is to split your view (and  
future code) of versium in tow part :
   - document as file / plain resource with versioning
   - meta-data of document / structured resource with indexing

Le 12 févr. 08 à 15:22, Andre Carregal a écrit :
> The way I see it, Sputnik is a curious case of "paradigm  
> overload"... :o)

IMHO, in this case, the split of requirement is a no-brainer, it would  
help to keep architecture clean and polyvalent.

Your advice ?

pierre
(who isn't very fluent in English and would better write  
blueprintcss.lua :) )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.luaforge.net/pipermail/sputnik-list/attachments/20080212/ecb948ad/attachment.html