Idea: network all things as sensors - not just location awareness. Sometimes LA doesn't help/isn't enough (need situation-dependent vs. loc-dependent, where situation may be loc-independent; or can supplement loc with situation). Power: charge up a 1F capacitor (15 min) and discharge it very slowly (~24 hr).
TEA "everything is a sensor" example: Sensors on mobile phone automatically switch receiver's phone to different profile when (eg) in meeting. "Context call" (shared ctxt between caller & callee): caller receives indication that callee is "in meeting", can choose to leave VM, send SMS, or cancel call.
Active artifacts: "Media cup" contains ucontroller and sensors that periodically read state of cup bottom and can compute "filled up", "drinking" (tilted), "gone cold", "sitting on table" etc.
Some thoughts: How about a "context server", and how to describe the ontology of context info it can serve? (Can this be cast as service representaiton/composition problem?)
Idea: embed networking, power, etc in surfaces themselves. Claims vs wireless; dedicated conns possible, vs. intrinsically shared; capable of providing (limited) power for charging, etc. Architecture: autonomous "tiles" and a surface manager all connected by a control bus and one or more data/power distribution buses. "Object controller" proxy negotiates with tile controller to get direct access to these buses via FPGA-controlled analog mux, so tile and object controllers are oblivious to semantics of objects' functions.
One issue: (temporary) disconnections confuse TCP and make it back off due to what it thinks are congestion losses. Should really use something like TCP Snoop, which they evidently hadn't heard of.
Some thoughts: Tiles aren't time-multiplexed but dedicated (circuit switched connections), so must be small enough that multiple small devices need not share. Are there RF interference problems wth adjacent tiles or to devices sitting on them? (A: not yet measured) How about accidentally spanning two tiles with a sweaty palm? (A: yes, it's a problem, usually no damage to hardware but could guarnatee that by using capacitive rather than conductive coupling between device and tile) How does RF vary with xmit speeds? SHould you not lay your credit card on a networked surface?
(This was very much an implementation detail talk. Not much discussion of architectural issues, what possibilities are opened up, etc. Basically a description of a [potentially] enabling technology without delving into what it enables and what the limitations are.)
Italics mark ways in which this appears to differ from iCrafter. We should work this into iCrafter paper for resubmit; it is definitely very close in a lot of ways.
Creates an abstract GUI description (not an abstract descrpition at the level of service behaviors) that works for "all" devices; each device is responsible for mapping the representation to its best fit GUI system (Swing/AWT, HTML, etc). MOCA framework maps GUI actions to method invocations. MOCA provides a hosting environment for apps, based on Java; for non-Java apps, an "app proxy" mediates method calls. Similarly to us, they use a servlet to convert HTTP requests into service method invocations (except that we do so indirectly thru the EH; they use a more direct method, where the backend method call goes through an "implementation proxy" that speaks whatever the remote service speaks (RMI, IIOP, etc)). An XML description file describes the service and the mappings between GUI and methods; that file is parsed by a "custom dynamic application servlet" that generates the UI and stays as the intermediary for method calls. Service discovery is handled thru a registry maintained centrally by MOCA.
Questions: Doesn't it adversely affect reliability to require 2 proxies to be running (in addition to the app/service) for this to all work?
Another important paper to cite.
Although this is not an on-the-fly service-UI generation system, it's more similar in spriti to iCrafter in that this system uses task models (among other things) to model what the user might want the application to do, and uses constraints to generate not just different UI's, but potentially different "faces" of a UI based on the current contxt. An AIO (abstract interaction object) is a portable description of this form that can be implemented differently on different devices. In contrast, a CIO (concrete i.o.) is more akin to a specific element in a GUI, eg a menu.
Example: constraint regarding screen resolution/size can be used to select one of three possible AIO's for implementing "choices": an imagemap, a text list, or a popup.
Question: how would this map to (eg) voice ctrl? A: there are already standard "abstract interactors" like choice, text input, etc. in VoiceML; unsolved issue is that the dialog structure itself would be different compared to a large-screen GUI (doesn't tax the working memory of the user; a typical problem with voice UI's, since they're serial and it's hard to have a sense of where in the UI you are).
Authors are with RedWhale software in Palo Alto; we should investigate what they do.
Ramon Caceres asked whether basically sometimes the interfaces have to be so radically different that "automated selection" of AIO's doesn't work well. Author agreed and so do I; does "behavior modeling" (what iCrafter does?) fix this?
Someone asked (for both AIO's and MOCA) how easy is it to touch up/hand-customize the auto-generated interfaces to achieve a pleasing UI. This is a feature we should play up in iCrafter. Speakers agreed that yes, touch-up is often desired, not clear these systems provide it. (Random point shared with Trevor Pering: It used to be that you could write more efficient specialized assembly code than C code. THese days that's mostly not true because compilers have gotten so good. Can this be reproduced with automatic human-interface "compilers"?)
Roma personal metadata services
[These comments are mostly for Appliance Computing]
Consider some of the basic problems used as motivation:
Appliance Computing can (if done well) yank the rug out from under this motivation by asserting that the very notion of a "single monolithic filesystem" is what leads to this mess: the notion of multiple copies of the filesystem, of filenames as the way to identify/name files, etc. all result from trying to extend the single-machine hierarchical FS metaphor as computing technology has progressed. (There has been work on content-addressable filesystems and the like, which is worth looking up; check the Summaries area and/or do a web search or ask a FS person.) The question is, what set of metaphors should replace the filesystem for appliance computing, and how can Roma help?