Protocol requirements: Difference between revisions
No edit summary |
No edit summary |
||
(3 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
''See also [[software requirements]] and [[hardware requirements]].'' | ''See also [[performance requirements]], [[software requirements]] and [[hardware requirements]].'' | ||
'''Protocol requirements''' for the [[healthy buying infrastructure]] seem to include at least: | '''Protocol requirements''' for the [[healthy buying infrastructure]] seem to include at least: | ||
Line 5: | Line 5: | ||
*[[HTTP]] and [[REST]] to the [[web browser]], as typical access to [[Development Wiki]] and [[Research Wiki]]. | *[[HTTP]] and [[REST]] to the [[web browser]], as typical access to [[Development Wiki]] and [[Research Wiki]]. | ||
*Each high-capability [[terminal device]] presenting a [[Consumerium buying signal]] | *[[Voice]] (or at least [[touchtone]]) control and [[audio]] communication to a [[headset]] for [[eyesfree]] and [[handsfree]] use at the [[retail shelf]] and [[checkout counter]], where people are typically too busy to look at screens. | ||
::[[DECT]] seems like the ideal way to provide both of these sets of services | |||
Beyond that, the following are optional: | |||
*Each high-capability [[terminal device]] presenting a [[Consumerium buying signal]] might have an [[IP number]] issued from a block someone controls. Every [[retail shelf]] might ultimately have one too, if [[friendly retail]] becomes the norm. | |||
*Ideally, some integration with [[ICQ]] or another [[chat net]] that can support [[SecureIM]] - see [[interwiki identity standard]] for more on this, which suggests [[jabber.org]] protocol may play a role in [[authentication]]. Possibly [[SMS]] also for communication between [[mobile device]]s. | *Ideally, some integration with [[ICQ]] or another [[chat net]] that can support [[SecureIM]] - see [[interwiki identity standard]] for more on this, which suggests [[jabber.org]] protocol may play a role in [[authentication]]. Possibly [[SMS]] also for communication between [[mobile device]]s. | ||
Line 11: | Line 17: | ||
::[[Consumerium Service access]] should include access to other users, especially if [[brand management]] types can pay to promote [[green light]] products to users, making it all [[self-funding]]. | ::[[Consumerium Service access]] should include access to other users, especially if [[brand management]] types can pay to promote [[green light]] products to users, making it all [[self-funding]]. | ||
[[Hardware requirements]] and [[hardware standard]]s constrain the protocols: [[Bluetooth]] for instance is assumed to be required to get both secure communication and [[modular hardware]]. But if [[in-store radio]] and [[audio]] presentation becomes a more effective way to deliver the [[Consumerium buying signal]], and [[privacy risk]] is not a concern, i.e. most of what is delivered is [[green light ad]]s, then: | :::Ideally since we have drifted from syntactically strict data format into [[wiki code]] that is easier for human cognition we should try to offer the '''avantgarde consumerist''' information and then rely on people getting into discussions over/on the information thus the [[healthy signal infrastructure]] is extended by word-of-mouth. | ||
[[Hardware requirements]] and [[hardware standard]]s constrain the protocols: [[Bluetooth]] or [[DECT]] for instance is assumed to be required to get both secure communication and [[modular hardware]]. But if [[in-store radio]] and [[audio]] presentation becomes a more effective way to deliver the [[Consumerium buying signal]], and [[privacy risk]] is not a concern, i.e. most of what is delivered is [[green light ad]]s, then: | |||
*In-the-clear [[FM radio]] may well be the most important protocol, with [[analog cell]] perhaps augmenting it. | *In-the-clear [[FM radio]] may well be the most important protocol, with [[analog cell]] perhaps augmenting it. | ||
*Entirely different protocols such as [[walkie-talkie]] or [[cordless protocol]] applications that call the customer back with an [[audio]] presentation on the product they just [[barcode scan]]ned, may also be more useful to support than anything based on an [[IP number]], if more phones end up with these capabilities. | *Entirely different protocols such as [[walkie-talkie]] or [[cordless protocol]] applications that call the customer back with an [[audio]] presentation on the product they just [[barcode scan]]ned, may also be more useful to support than anything based on an [[IP number]], if more phones end up with these capabilities. |
Latest revision as of 22:14, 10 April 2004
See also performance requirements, software requirements and hardware requirements.
Protocol requirements for the healthy buying infrastructure seem to include at least:
- HTTP and REST to the web browser, as typical access to Development Wiki and Research Wiki.
- Voice (or at least touchtone) control and audio communication to a headset for eyesfree and handsfree use at the retail shelf and checkout counter, where people are typically too busy to look at screens.
- DECT seems like the ideal way to provide both of these sets of services
Beyond that, the following are optional:
- Each high-capability terminal device presenting a Consumerium buying signal might have an IP number issued from a block someone controls. Every retail shelf might ultimately have one too, if friendly retail becomes the norm.
- Ideally, some integration with ICQ or another chat net that can support SecureIM - see interwiki identity standard for more on this, which suggests jabber.org protocol may play a role in authentication. Possibly SMS also for communication between mobile devices.
- Consumerium Service access should include access to other users, especially if brand management types can pay to promote green light products to users, making it all self-funding.
- Ideally since we have drifted from syntactically strict data format into wiki code that is easier for human cognition we should try to offer the avantgarde consumerist information and then rely on people getting into discussions over/on the information thus the healthy signal infrastructure is extended by word-of-mouth.
Hardware requirements and hardware standards constrain the protocols: Bluetooth or DECT for instance is assumed to be required to get both secure communication and modular hardware. But if in-store radio and audio presentation becomes a more effective way to deliver the Consumerium buying signal, and privacy risk is not a concern, i.e. most of what is delivered is green light ads, then:
- In-the-clear FM radio may well be the most important protocol, with analog cell perhaps augmenting it.
- Entirely different protocols such as walkie-talkie or cordless protocol applications that call the customer back with an audio presentation on the product they just barcode scanned, may also be more useful to support than anything based on an IP number, if more phones end up with these capabilities.