Next big thing

[Jack Coats]

Try a secure generic 'link keeper' web site.  Use a reasonably secure 
authentication, to allow people to store links, even better, 
link/userID/password/PIN numbers/lock combinations, and a few associated 
notes.  Also allow keeping of program keys - vendor/program/version/userID-
registered username/key data.  Put in PGP/etc type 
userID/fingerprint/publickey/private key information for use in other 
software. ... There is already some software like this, but make it very 
secure, very easy to use, very inexpensive, and very portable would be great.

This could be something taht could run as a secure web service, and download 
to a PDA for a 'mobile' version.

Find a new app that could take advantage of a 60G Ipod or that type of thing.

Searchable database to track my cd/dvd collection for video, audio, VCD, 
programs, distributions, and link it back to the 'link keeper' thoughts above 
for secure access and access to keys. ... Put in a link to access the media 
via a jukebox.  Make the database extensible to associate other 'files' with 
the media information (what files are on the media, link to CBBD or wahtever 
it is called to get free media information about artist).

Generate a media database systems that allows not only keeping info as other 
services do for artist and performance media, but links to vendors for 
updated software fixes, etc.  Use a standard (xml?) but make whatever easy to 
use so script type folks can use it too.  

Figure out a hook to a generic file system and make an HSM system using the 
same file/media/attribute tracking from above, but also manage where the data 
is stored and allow retrieving.

Generate a real distributed file system - redundant and self healing for 
multiple architectures. .. this may be a bit much.  Allow a virtual file 
system that stores files (in a RAID type method) over spare disk space over 
multiple nodes.  Do not lock this to a particular type of node (Windows, 
Linux, BSD, Solaris, etc) but allow the space to spread over all nodes.  The 
more nodes, the more redundant and spread out the file system.  Allow data 
to 'migrate' around the storage network, so keep track of the last few places 
it was used, and migrate the data to the most used nodes.  If one node from 
somewhere else accessed the data, do not migrate the data there, but if it is 
used several times over a time period, then allow migration.  Always keep 2 
preferably 3 or 4 copies of the same data on different nodes, for redundancy, 
and if a node is turned off (being re-booted, or really discarded) the data 
is still 'in the net'.  As long as all the nodes are not 'offline' the data 
would still be available for access, and if only one or two copies are 
online, automatically start making a copy on another 'somewhat empty' node. - 
Every node that accesses data could be a 'server' node also. ... Keep track 
of 'redundant' data storage, and note they are the same file, at different 
points in the entire file system structure. ... this would keep down the 
amount of data to store, but have it still be redundant. ... this kind of a 
file system is not for FAST access, but for secure from hardware failure 
access, but would try to 'self optimize' as much as possible.  Files that get 
accessed more often, may need more copies on more nodes (instead of 4 or 5 
copies over 50 nodes, it may need 10 or 20) depending on use. ... even the 
database and tracking portions that would go into its database portion of 
this project would be a great couple of months of database design and 
implementation work.

If this doesn't keep you busy, ask again, I am sure there are more ideas 
available.  BTW, give me a 'free copy' if you use one of these ideas, and if 
you get rich, share the wealth! :) ... Jack

-- 
   Keep your critical files backed up and secure
 - - > Dr.Backup Remote Online Backup Service < - -
 > 30 day free trial period--Free help with setup <
        http://www.drbackup.net?pid=Coats 
(Extra FREE storage when you sign up using the full link above)

---------- Original Message -----------
From: markw at mohawksoft.com
To: discuss at blu.org
Sent: Thu, 2 Dec 2004 07:54:49 -0500 (EST)
Subject: Next big thing

> I've had some extra time lately, and been trying to think about a project
> that I can write in a few weeks/months that might be useful. 
> (Marketable?)
> 
> I just can't think of anything interesting to write.
> 
> I have a simple web services framework that has file and SQL/XML 
> code. I wrote a SQLite driver so it could be self contained if 
> people didn't want to use a bigger DB. I have a recommendations 
> engine, a full text search engine, a high speed session/cache system 
> for web server farms.
> 
> I'm toying with the idea of "hard-linking" the web services 
> framework, the SQL/XML module, and SQLite as a zero configuration 
> SQL database.
> 
> Any ideas welcome.
\