adhoc roadmap

[thi <ttn@mingle.glug.org>]

hi everyone,

for those just tuning in, adhoc is a presentation framework currently in
development.  its goals are to be as general and extensible as usefully
possible.  presentation should be interactive (to a certain degree) and
definitely adaptive to environment.  thus, the hack on the non-visible
side: adhoc should be able to apply heuristics to discern various things
such as user mood, presentation interest, and even presentation content
where unspecified.

the visible side should talk to any number of displayers, but minimally
have text output.  the hack here would be to get everything translated
to ascii real-time for display by emacs.  ascii animations in a buffer
would be way cool (and useful for those not running X).

here are some ideas for adhoc:

- 10fps translation of images to ascii, and other
  inferior gimp possibilities
- port some xemacs niceties to emacs, and use
- conformance to existing (?) presentation MLs
- partial catalyst for emacs/guile integration
- inference engine (for content generation, user analysis, etc)

i am open to architectural (design) munges as well.  we see that certain
forkings of late are due to the perception of closed architecture.  if
you are interested in helping, consider doing one or more of:

- inferior gimp research
  - is there a current external protocol defined?
  - what overhead can be shaved?

- image transform research
  - is there a *2ascii library?
  - has it been wrapped for gimp?

- emacs/xemacs schism research
  - what happened and why?
  - anyone working on re-unification?

- presentation ML research
  - what was that X app released over the summer that could
    embed sub-apps?  external protocol?
  - others?

- subsystem design and implementation
  - should adhoc be multi-threaded?  if no, when to re-ask?
  - what is the appropriate level of heuristic integration?
  - what is the event model?

all the research tasks have an additional question: what is reasonable
performance for a glue-level workaround?  the implication is that the
research is focused on finding existing solutions that require minimal
tweaking.  the less we need to do, the easier it is to relax and have
fun.

this all is a first cut at project organization.  suggestions and
feedback welcome.  i haven't thought about a schedule because i don't
know the resource allocation and, besides, all fun projects never end.
some reasonable milestones can be useful, however (tbd).  the outer
bound suggested for edutainment by another poster should be doable.

ultimately, the idea is to have a screensaver that trundles around the
filesystem (or net) spewing interesting things at you while you sit
sipping a beverage of choice, but better than tv because you can
interact w/ it.  whether or not this is educational depends on usage
and, of course, on your point of view.

with respect to the referenced _Diamond Age_, think of books as manual
screensavers.  :->

cheers,
thi