View Single Post
Old 02-13-2009, 02:02 AM
teratorn teratorn is online now
Registered User
Join Date: 11-20-2006
Posts: 33
Originally posted by quant
security, gmail, you made my day
Hehe, thanks

One thing here I want to add to the discussion... I think it's important that we don't start trying to overthink the
"problems" here... it strikes me that I've thrown together a LOT of information in the thread, because I
was reaching for the stars.

So, I've been sitting here for the last 10 minutes thinking of the simplest, most straight-forward thing
that Kinook could do to start unlocking peoples' Info Databases to the power of a programming language,
and thereby to the pool of talent that already lies within the user community - a pool of talent that will most
certainly grow as a result of definite steps to facilitate it. The fruits will be slow in coming, or so it may seem at
times, but that shouldn't stop anyone from sowing such well-conceived seeds.

So, A definite proposal:

- The information contained in an Info Database.. the real meat & potatoes of the content we collect and
create needs to be accessible and modifiable by Plugins.

- Plugins must be distributed as source code packages... no precompiled binaries. The only people I
trust to run binaries from is Kinook, and nobody is adding to my list here without code review being

- Design and implement a Data Access Layer that gives read-write access to nodes in the tree, and various
other bits of data that fit here, but don't actually live in the public tree (Settings, perhaps? read-only?). This is
the BIG ONE. I've already talked above about this layer, so please refer to those notes, and also keep clearly in
mind that we *want* to program according to the "Ultra Recall model" that we are all *already* familiar with...
e.g. the data query API should work just like the advanced search window. Perhaps Kinook has already
implemented such a data layer internally? Sounds like a likely guess.

- Utilize the Python programming language for its ease of learning, wide-spread adoption, huge user
community, and it's professional programming power (not to metion it's free and open-source).

(Python is written entirely in C (with much of the standard library and utilities being written in Python
itself. This makes it attractive to UR since UR is written in C++. Python provides both C and C++ APIs. Kinook
would need to author an "ultra_recall" C "extension".. this process is documented. That extension would
implement the interface to UR's internal API and data structures, and expose them via nice Python APIs).

- Utilize a "setuptools"-based solution for Plugin packaging and distribution... almost all the challenges
that Kinook would face in managing dependencies between Python-based plugins can be solved by using
this as a starting point... we simply need to ensure that any security concerns are addressed, and that we
aren't coding ourselves in to a corner in any way.

- New "Plugin Security" attribute that can be set on any node in the tree.. values of "No Scripting Access", "Read-
Only", "Read-Write". The setting is recursive to child nodes. This is an easy way to "protect" data from any
access by Plugins... this peace of mind goes a long way for me... I don't want Plugins to be messing around
behind my back.. much better to just expose those parts of my tree explicitly.. or if I prefer, for some DBs, I
can set this attribute on the root node. Yay.

- People can start posting Plugins to a special forum up in here... to get started with... trust will be vested in the
author's reputation and in reviews/comments and the fact that anyone can read the source code to the plugin.

That's really it... SQLite + Ultra Recall + Data Layer + Python == FUN.

Consider this an offer of assistance... I'm happy to answer questions via email whereever I could lend my
expertise... I've been writing Python since 1999, and I have a lot of professional coding experience. But maybe
this is better done through separate blogs, or a shared Trac instance, or some other public forum (this forum is
not really ameanable to "semi-internal" discussion between developers). I wish to invest more heavily in
my own usage of UR, and I'm starting to put a lot of other people on to it as well... so doing this kind of
work is just a good investment in my future.

Let the good times roll...
Reply With Quote