[My apologies, I wasn't meaning to burden the group with that message; nothing in it is a secret. Just a mistake due to trying to post during my lunch hour while using a rather sorry excuse for a webmail.]
If I can find the time I'll post a better description of the provider project. For now I'm simply trying to get myself up and running to post the wiki plugins described a bit earlier. Cheers, Murray > [offline] > > Hi Juan Pablo, > > Thanks for the info, that's very helpful. I've updated my Eclipse from > the master but still get one error, a generics mismatch on rss.jsp. But > for whatever reason that's there it won't stop me from continuing. > > It does sound like I should work from a branch though, not necessarily > for the plugins, but for the providers, as there might be some contention > there. How does one go about creating a branch, and what might be an > appropriate name? > > To give you an idea of what I'm working on, it's a set of three providers, > based on a text-based format for wiki pages called a "Ned" (as my parent > project is called 'ne' and it's referred to as a "ne node"), A Ned is a > text format, using a model influenced by the original Macintosh file > format, > which divided the file content into a "resource fork" (file metadata) and > a > "data fork" (file content). This uses an untypeable delimiter character to > separate the forks. > > I've currently got four providers, three of which are finished: > > 1. an in-memory provider for testing only > 2. a Berkeley DB JE based provider > 3. a Neo4j Embedded graph database provider > 4. a Neo4j OGM graph database provider (unfinished) > > It wouldn't be too difficult to develop a file-based provider since there > are already Ned serialiser and deserialiser methods in the code. > > The Neo4j providers have a 32K data limitation on any single property, > (due to a current limitation in Neo4j) so wiki pages over 32K get > segmented > and re-built when pulled from the repository. > > Full-text and field-based search is currently via Lucene using a separate, > non-JSPWiki API, not sure what to do about that. > > I haven't advertised this project to the group yet because I'm not sure > I'll > have enough time to actually convert it over to JSPWiki and get it up and > running on my own. I can probably publish some of the plugins but the > providers are a significantly larger venture. While the benefits of a > graph > database backend for a wiki may be apparent to some, the Berkeley DB > version > is probably enough of a win to promote the basic Ned project, even without > the Neo4j providers. It's exceedingly fast and is a very stable DB. > > This all comes out of a project called 'ne', a CLI-based application I've > written to capture and store text-based notes. Basically, the idea is that > one could write notes that are easily turned directly into wiki pages, > without needing to use a wiki. Ne also has a directory watcher that can > auto-ingest anything dropped into it. It's got more features than that, > suffice it to say that the Neo4j providers are coming out of ne's storage > backend, which is an embedded Neo4j. > > Ne's metadata model is configurable via a JSON file. Ne uses a more > complicated model than JSPWiki but they're by design compatible. > > As you may imagine, the enemy in all this is, as always, time available. > > ...enough for now. ........................................................................... Murray Altheim <murray18 at altheim dot com> = = === http://www.altheim.com/murray/ === === = = === In the evening The rice leaves in the garden Rustle in the autumn wind That blows through my reed hut. -- Minamoto no Tsunenobu
