path: root/hurd/translator.mdwn
diff options
authorThomas Schwinge <>2009-01-19 13:09:16 +0100
committerThomas Schwinge <>2009-01-19 16:01:01 +0100
commit27d13175ccd378e4d3531176276475dd84af5fed (patch)
tree625411d59b83ecc8339bbedebc49f41968101371 /hurd/translator.mdwn
parent601bba64b7b2b4e5c499ea4258bb89743133ff5a (diff)
Move some pages, remove others that are either out of date or whose content is duplicated somewhere else.
Diffstat (limited to 'hurd/translator.mdwn')
1 files changed, 4 insertions, 120 deletions
diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn
index 0823f0d..0cfcc5f 100644
--- a/hurd/translator.mdwn
+++ b/hurd/translator.mdwn
@@ -73,123 +73,7 @@ available.
* ...
-# Translator wishlist
-* [[devfs]]
-* FUSE( compatilbility library. : just modify FUSE apps a and compile little to work as translator :-)
-* File Finder. (uses find, grep, a combination or a custom command (htdig, mp3 info)
- * Files found will be available under one directory and then can be used like a normal directory
- * usefull to generate Albums, Share only resulting files over the et, etc..
- * The filefinder can be scheduled or can be connected over some ipc like dbus to the VFS system if any to keep a watch for new files.
-* GNOKII, BitPim and openobex as translators
- * grep through your SMSs!
- * share your addressbook!
- * "Attach" that funny SMS/MMS to your email.
- * "svn commit" your joke collection :-D
-* Real Language Translator [[br]]
- * cat /usr/translator/de-en/usr/share/doc/something.txt should take /usr/share/doc/something.txt , submit it to google's website and bring back results.
-* Mozilla Bookmarks = del.ici.ous
- * Need more explanation ? ;-)
-* <>
- * having a directory structure for a file can allow to "svn commit" the hnb document in a more "node-safe" manner, thus allowing multiple people to work on the same hnb document.
- * This must be fairly easy as HNB can already export to XML and XMLfs already exists.
-* DavFS
- * Just setup a 'WebDav share' as a directory. The implimentation of the protocol is already available in nautilus and konqueror.
-* Compiled form of your project
- * you have your project in /somedir/project with source in /somedir/project/src .. /somedir/project/bin should always have the compiled version.. is it possible?
- * The source has to have a MakeFile.
- * creating /somedir/project/bin-somearch should aotomatically crosscompile
- * Seems feasible for a small project.
-* Report generation FrameWork - an idea to be hugged by app developers..not kernel developers.
- * You have financial data in some Spreadsheet like format in /yourFinance directory
- * You add report templates to /yourFinance/repTemplates
- * Once you save data in /yourFinance the next cat /yourFinance/reports/areportname will give you an uptodate report.
- * This will be usefull for any purpose including serving by static page web servers, sharing over samba/nfs/ftp etc.!
- * The advantage is any save to the spreadsheet will update the report.. not just from one software.
-* SVN (Subversion suite)
- * like [[cvsfs]]. /svndir/version/version-no should automatically have subversion
- * I think it is nice to write a generalised version control system framework library which will help in writing version control translators and other tools easily.
-* Flexi-acls
- * First of all - Can this be done? : A translator bound to a directory must be able to access the contents of the directory which would have been accessible in the absence of the translator..
- * This will enable to wirte translators that can implement custom "Access Control Lists". Just imagine having advanced ACLs even if underlying FileSystem is dumb! Imagine changing the type of ACLs implemented with Just two commands - one to unattach previous translator and the next to attach a different ACL translator! The ACLs themselves may be stored in a different directory
-* The translator manager!
- * Some translators will need to be inserted automatically - like for eg: hardware drivers ..
- * Each hardware translator will pubish its capabilities.
- * The "top" translator will query the capabilities of different hardware and match capabilities with the "slave" translators. That is it's only Job.
- * The control is then handed over to the slave translator.
- * The ranking not only looks who can handle the "most" capabilites of the hardware. If it finds that multiple translators can handle the same hardware, It will use other parameters to choose between them.. like may be the size in memory? The revision date? Stability (inferred from version number)? And to go to the extreme, the profiling data of the driver ;-P
- * Advantage : The best driver wins!
-* An eg. Skip it if you understood the above :-):
- * You have a driver that can handle VGA + SVGA + Super3d acceleration + Particle graphics + Works for nvidea card.
- * You have a driver that can handle SVGA + VGA .
- * You have a driver that can handle VGA.
- * Case 1: Your card: A VGA card with some extra fonts..
- * First the VGA driver will be quireied .. ok can handle essential capability.
- * Next SVGA driver: can handle but has extra module.. unnecassary weight .
- * The Nvidia driver: can handle , but again unnecassary weight : ruled out.
- * Winner : VGA driver:
- * Case 2: Your card An SVGA card:
- * First the VGA driver will be quireied .. ok can handle one essential capability.
- * Next SVGA driver: can handle essential and one extra capability no extra weight..
- * The Nvidia driver: can handle , but unnecassary weight : ruled out.
- * Winner : SVGA driver..
- * Case 3 : You have an VGA .. but no VGA driver .. then the SVGA driver would win.
-* Sound Server
- * /ahsa - stands for Advanced HURD sound architecture :-) Just a temporary name .. for fun.
- * /ahsa/out - directory wich will hold "plug"s where apllications come and join the server .. see below.
- * /ahsa/out/mixer - main mixer
- * /ahsa/out/nextfree - the file when "cat"ed gives the number of the next free plug
- * /ahsa/plugins/ - info about available plugins
- * /ahsa/out/[1..n]/ - dynamically generated directories for applications to plug on..
- * /ahsa/out/[1..n]/data this is where you should do a "cat somerawsoundfile>/ahsa/out/`cat /ahsa/nextfree`/data"
- * /ahsa/out/[1..n]/plugins - the plugin stack .. volume is also a plugin..
- * /ahsa/out/[1..n]/plugins/[1..m]/ - echo "plugin param1 param2 param3" > /ahsa/out/[1..n]/plugins/`cat /ahsa/out/[1..n]/plugins/nextfree`/add
- * /ahsa/out/[1..n]/plugins/[1..m]/params/{param1.. paramn}
- * /ahsa/out/[1..n]/data.out - can be catted to get data processed through the server
- * /ahsa/in - similar to /ahsa/out .. with except for an extra file to choose input devices.
- * /ahsa/devs/{1..n} - devices detected .. can be dynamic .. there are usb soundcards and and midi devices.
- * /ahsa/out/[1..n]/plugins/[1..m]/0/params/dev
- * Dont get tempted for :/ahsa/out/[1..n]/params/{rate, channels, and other stuff}
- * that goes into /ahsa/out/[1..n]/plugins/0/params if /ahsa/out/[1..n]/plugins/0/detected == "headerless audio"
- * There are a lot more things I can continue about the "sound server" .. The Ideas simply dont seem to exhaust..
- * Some features/advantages
- * set output's translator plugin as ordinary text -- have text to speech conversion done by sound server!
- * Create and apply plugin presets by simply copying directories!
- * Me getting dizzy thinking of the zillion more advantages.
- * If you are really doing some ordinary output , all you need to do is "cat" data into next free "plug" and everything will be autodetected including the format of the data and sent to the final sound "merge"r
- * Dizzy ...
-* /usr/share/menu !!!! extension for package management idea ..
- * cat >> /usr/share/menu/menu
- * cat /usr/share/menu/debian/kde ... :-)
-* Spam/Malware Control
- * /usr/antimalware/ - put your mail here.. it will automatically be scanned. when finished it will vanish from here ..
- * /usr/antimalware/clean - ... and pop out from here
- * /usr/antimalware/malware - or here.
-* NetDevice
- * !JustImagine(tm)... settrans -ac /netdevices /hurd/netdevfs - [ host | net ]
- * One can access device files remotely
- * This could be acheived by allowing translators talk to one another over a network
- * This will need translators to catch and handle ioctls (if there is such a thing in HURD).
- * The device server which will listen to requests from the translators can be run even on a Linux machine!!!
- * !JustImagine(tm)... accessing the crwriter/webcam on that GNU/Linux machine on the network using cdrecord of your local hurd machine!
- * !JustImagine(tm)... running GNU/HURD on a minimalistic GNU/Linux(but with all the drivers) through a specially modified and optimised Qemu. The device server runs on the host machine, and the client translators access over the virtual network created by Qemu. You got most of the drivers for free!
-* Emacs File VFS
- * I came to know from my Emacs loving friend that there are lots of VFS handlers in Emacs.. I was wondering if there can be translator which can tap into these Emacs VFS handlers.
+# Translator Wishlists
+ * [[wishlist_1]]
+ * [[wishlist_2]]