Re: [6lowapp] Really we need for HTTP on smart devices?

I totally agree with you! I don't think I ever said that "everything  
in the world must be a web server". Of course I'm in favor of rfid and  
hacks and barcodes to get data about the real-world on the web and  
even better when it doesn't need a web server or not a machine.

What you say really feels like you're trying to convince me about  
something we both know and agree with (just like every one else here I  
guess), so I don't see the point of discussing that.

When it comes to electronic devices I think HTTP is sufficient for  
many applications (again not all, just many), but as Adam points it  
out, it's not perfect for everything. I simply disagree with your  
comment "SunSpot is fine but for 6lowpan we have 60-80 bytes of  
payload and 10kbps in application throughput to deal with.".

I'll also add another example: Smews is a web server able to do comet (http://en.wikipedia.org/wiki/Comet_%28programming%29 
) with 100's of simultaneous subscribers (devices push http  
notifications to the subscribers) with decent amount of time. Smews  
needs 8kb and has been running on a standard msp430-based sensor node.

It's certainly slower than custom solutions, but it's there and works,  
and if you want to collect a temperature reading every minute, that's  
more than enough.

On Oct 30, 2009, at 3:59 PM, Adriano Pezzuto (apezzuto) wrote:

> Vlad/Don,
> thanks for your feedbacks. Nice to see starting a debate here.
>
> Vlad,
> I know your work at the Web of Things and it's fine.
> On the other side, today we do not see many real 6lowpan devices  
> able to support HTTP on TCP. SunSpot is fine but for 6lowpan we have  
> 60-80 bytes of payload and 10kbps in application throughput to deal  
> with.
>
> It looks that HTTP on 6lowpan is a sort of "I wish but I cannot" and  
> gatewaying/proxying is only a compromise not a solution. I'm try to  
> find different points of view, so my initial question.
>
> Please have a look to this interesting paper from Tim O'Reilly and  
> John Battelle:
>
> http://www.web2summit.com/web2009/public/schedule/detail/10194
> "
> Many who talk about "the Internet of Things" assume that what will  
> get us there is the combination of ultra-cheap RFID and IP addresses  
> for everyday objects. The assumption is that every object must have  
> a unique identifier for the "Internet of Things" to work.
>
> What the Web 2.0 sensibility tells us is that we'll get to the  
> Internet of Things via a hodgepodge of sensor data contributing,  
> bottom-up, to machine-learning applications that gradually make more  
> and more sense of the data that is handed to them. A bottle of wine  
> on your supermarket shelf (or any other object) needn't have an RFID  
> tag to join the "Internet of Things," it simply needs you to take a  
> picture of its label. Your mobile phone, image recognition, search,  
> and the sentient web will do the rest. We don't have to wait until  
> each item in the supermarket has a unique machine-readable ID.  
> Instead, we can make do with bar codes, tags on photos, and other  
> "hacks" that are simply ways of brute-forcing identity out of  
> reality. "
>
> Regards,
> Adriano
>
>
>
> -----Original Message-----
> From: Vlad Trifa [mailto:trifa@inf.ethz.ch]
> Sent: venerdì 30 ottobre 2009 13.35
> To: Adriano Pezzuto (apezzuto)
> Cc: 6lowapp@ietf.org
> Subject: Re: [6lowapp] Really we need for HTTP on smart devices?
>
> Hello,
>
> Adriano: the web of things is exactly going beyond the "web
> information shadow" as you put it. We've been putting data from
> devices on the web since a decade, so what? nothing new there, but if
> you can turn devices by design into actual web actors (just as any
> other Web server), it open doors and completely new design
> possibilities as opposed to just make their data available on the web
> - it's a completely different (or broader) way of viewing things.
>
> Well, I think the "HTTP is too heavy" argument is certainly valid when
> you have very tight/specific requirements and need to maximize the
> throughput of your communication. Of course it is a verbose protocol,
> but you might gain a lot of using it directly on devices, especially
> in terms of application level interoperability, and even more
> important for plug & play integration with the Web and Web
> applications. Let's put it that way: how many people know/use the
> zillions application protocols/middlewares available (I don't want to
> mention any, because many are excellent for specific applications, but
> I don't believe much in the *perfect* middleware) hundreds? maybe
> thousands? Ok and now how may people use http/xml? I think you get my
> point here.
>
> Indeed, what you lose in performance (and it's not as bad as one
> thinks) you gain in terms of integrability. When I think smart homes,
> I think many constructors need to agree on a protocol. But I also
> think few messages here and there to control lights/HVAC and read
> energy meters with sub-second delay requirements. I don't think,
> thousands of messages per second nor high-frequency distributed
> sampling. Eventually, we want to reuse infrastructure that's already
> there (web), so why not use and adapt http/xml directly for that
> matter, as we need to design an application protocol anyway?
>
> Of course one can use gateways for doing this, but if you can have
> directly http on devices, then your gateway simply become routers
> across physical interfaces, and it's much faster because you don't
> need to open or understand packets passing through.
>
> Then if you think lots of concurrent people reading all types of http
> sensors from all types and constructors, then you can simply pop in a
> squid or any web cache, and voila, massively scalable infrastructure
> to store data (we got 20 years of experience with the web and the
> associated techs, so why reinvent the wheel when it rolls where you
> want?).
>
> I shall stop here, and please have a look at some of our work, I think
> we try to motivate and illustrate that exact point well there:
>
> http://www.vs.inf.ethz.ch/publ/papers/guinardSensorMashups09.pdf
> http://www.vs.inf.ethz.ch/publ/papers/dguinard_09_WOTMashups.pdf
>
> However, sorry I don't get the "humans don't have a web server"
> argument, what is your point with that?
>
>
> Vlad
>
>
> On Oct 30, 2009, at 1:02 PM, Adriano Pezzuto (apezzuto) wrote:
>
>> Hello,
>> there is a lot effort to push HTTP and REST interfaces on smart
>> objects
>> assuming that smart devices (sensor/actuators/readers) should act as
>> Web
>> providers. On the other side, 6lowpan and other wireless sensor
>> networks
>> are made by resource-constrained embedded devices so HTTP looks like
>> too
>> resource expensive.
>>
>> We are seeing a lot of proxying and gatewaying solutions to bring  
>> HTTP
>> and REST on the 6lowpan devices. But working with gateways and  
>> proxies
>> are always struggling especially at application level. My question
>> here
>> is why we need to bring HTTP on smart objects?
>>
>> Smart objects interact with the Internet as they like (and can) as
>> humans do. Humans type on a computer keyboard or play in front of the
>> iPhone camera while Things send sensing data or get commands to act  
>> on
>> the real world. Humans do not have an embedded HTTP server even if  
>> the
>> results of their actions (i.e. typing on a keyboard and playing in
>> front
>> of a camera) are available as Web resources. In the same way, Things
>> do
>> not need for an embedded HTTP server. Things interact with the
>> Internet
>> using a lightweight protocol while the results of their interaction
>> are
>> available on the Web as resources. It is a sort of "information
>> shadow"
>> data that Things have on the Web. This data will be collected in a
>> suitable manner for the resource-constrained embedded devices and  
>> make
>> available as Web resource with HTTP and REST interfaces.
>>
>> What do you think about it?
>>
>> Regards,
>> Adriano
>>
>>
>> _______________________________________________
>> 6lowapp mailing list
>> 6lowapp@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lowapp
>