[openARweb] communication protocol: WFP vs HTML5 vs ???
6 views
Skip to first unread message
Davide Carnovale
May 3, 2010, 12:51:13 PM5/3/10
to open...@googlegroups.com
Hi all,
here are some thought on the advantages/disadvantages of WFP (wave federation protocol) and HTML5
- near realtime communication: both WFP and HTML5 (with web sockets) satisfies this requisite and both of them needs a custom server to be run,
so no big differences here. But we might want to consider performances in a further stage.
- user generated content: This is easier in WFP because you don't need to know HTML, you don't need to have a server to host your content,
you don't need to now tech details about granting/restriting access to your data. This is all "free" with WFP. On the other hand HTML sites
can offer easy content creation (like a blog or a forum do now) but that depends on who host the site and it's not something you can give for granted.
- accessibility of content: HTML5 is public in it's nature and this is good; but there are some cases where a login is required.
The disadvantage of this, is that many websites = many logins (with some exceptions like openID). WFP is private, in the way it requires a login,
but on the other hand, one login = access to all federated content. There could be still cases where WFP servers aren't federated and additional
logins can be needed though. So this seems to show that there are no big differences here too. But again, as for UGC, managing access is easier
and already built-in in WFP (though it needs some refinements in terms of granularity imho).
As Thomas noticed: "HTML is based around the idea of one->many delivery of content. The only way you can get private or group communication on the web is on
social networking sites. Aside from being a lot more effort to code and run, this hands over a lot of control too third partys and (as we can see)
is causing the internet to fracture a bit. We are getting huge "nodes" like facebook running a lot of the data, rather then it being distributed
evenly.
Its hard to conceptualise this neatly, but WFP is more like a email system, it lets us communicate with friends and groups, but doesn't require
the other party's to be using the same server/host as you. It also doesn't prioritise its traffic. With HTML the social-content will always be
"second tire", hosted within another site. With wave all content, regardless of host, will be delivered the same way and have equal footing."
- social communication: this feature is builtin in WFP but lack totally on HTML and it's demanded to the site admins, which chould provide a chat
or something. So again, much is demanded to the site hosters, which could not implement the same method, and this will mean more work on the client
side to support different communication protocols. On the other hand, in the WFP there's the same problem if we plan to support external services
(like twitter, four square)
- adding functionality: in HTML you need to develop a plugin for the sw running on the webpages and you need to have access to the server to do so.
This usually means complete power over the data, but it's not something that external developers can do. So again, you have to rely on what
the server admins give to you. On WFP there are the robots. Anyone can develop and host them somewhere and every user can add bots to their waves.
This means that more developers are able to add functionality to the system, and that all users have a complete freedom about what functionality
they want into their waves.
- what should an "old style" browser see when pointed to AR pages: this is another problem that needs to be explored. Not all AR data fits into
a web page, so, should we take into account an alternative visual rendering when the data has to be displayed in a non AR-capable device? This is
a problem for both WFP and HTML, in fact we're planning to use WFP annotations which are invisible to the user via a traditional browser. Adding hidden
metadata to web pages could be a similar workaround if we decide to go for HTML. Nevertheless the main problem remains in both cases.
what do you think?
do you have suggestions for other protocols we should take into account?
Davide
here are some thought on the advantages/disadvantages of WFP (wave federation protocol) and HTML5
- near realtime communication: both WFP and HTML5 (with web sockets) satisfies this requisite and both of them needs a custom server to be run,
so no big differences here. But we might want to consider performances in a further stage.
- user generated content: This is easier in WFP because you don't need to know HTML, you don't need to have a server to host your content,
you don't need to now tech details about granting/restriting access to your data. This is all "free" with WFP. On the other hand HTML sites
can offer easy content creation (like a blog or a forum do now) but that depends on who host the site and it's not something you can give for granted.
- accessibility of content: HTML5 is public in it's nature and this is good; but there are some cases where a login is required.
The disadvantage of this, is that many websites = many logins (with some exceptions like openID). WFP is private, in the way it requires a login,
but on the other hand, one login = access to all federated content. There could be still cases where WFP servers aren't federated and additional
logins can be needed though. So this seems to show that there are no big differences here too. But again, as for UGC, managing access is easier
and already built-in in WFP (though it needs some refinements in terms of granularity imho).
As Thomas noticed: "HTML is based around the idea of one->many delivery of content. The only way you can get private or group communication on the web is on
social networking sites. Aside from being a lot more effort to code and run, this hands over a lot of control too third partys and (as we can see)
is causing the internet to fracture a bit. We are getting huge "nodes" like facebook running a lot of the data, rather then it being distributed
evenly.
Its hard to conceptualise this neatly, but WFP is more like a email system, it lets us communicate with friends and groups, but doesn't require
the other party's to be using the same server/host as you. It also doesn't prioritise its traffic. With HTML the social-content will always be
"second tire", hosted within another site. With wave all content, regardless of host, will be delivered the same way and have equal footing."
- social communication: this feature is builtin in WFP but lack totally on HTML and it's demanded to the site admins, which chould provide a chat
or something. So again, much is demanded to the site hosters, which could not implement the same method, and this will mean more work on the client
side to support different communication protocols. On the other hand, in the WFP there's the same problem if we plan to support external services
(like twitter, four square)
- adding functionality: in HTML you need to develop a plugin for the sw running on the webpages and you need to have access to the server to do so.
This usually means complete power over the data, but it's not something that external developers can do. So again, you have to rely on what
the server admins give to you. On WFP there are the robots. Anyone can develop and host them somewhere and every user can add bots to their waves.
This means that more developers are able to add functionality to the system, and that all users have a complete freedom about what functionality
they want into their waves.
- what should an "old style" browser see when pointed to AR pages: this is another problem that needs to be explored. Not all AR data fits into
a web page, so, should we take into account an alternative visual rendering when the data has to be displayed in a non AR-capable device? This is
a problem for both WFP and HTML, in fact we're planning to use WFP annotations which are invisible to the user via a traditional browser. Adding hidden
metadata to web pages could be a similar workaround if we decide to go for HTML. Nevertheless the main problem remains in both cases.
what do you think?
do you have suggestions for other protocols we should take into account?
Davide
Mike Liebhold
May 3, 2010, 3:31:07 PM5/3/10
to open...@googlegroups.com, Davide Carnovale
David,
It seems you comments are confusing several dimensions simultaneously.
It might be helpful to narrow these discussion.
See comments interleaved:
On 5/3/10 9:51 AM, Davide Carnovale wrote:
> here are some thought on the advantages/disadvantages of WFP (wave
> federation protocol) and HTML5
Is this an either/or situation?HTML5 is fais d'accomplin the web display
markup which wil inevitably be included in AR., XMPP is an Extensible
Messaging and Presence Protocol. Shouldn't you be contrasting XMPP with
HTTP?
> - user generated content: This is easier in WFP because you don't need
> to know HTML, you don't need to have a server to host your content,
This patently a false argument. Millions of people will know how to
program HTML5 media
> you don't need to now tech details about granting/restriting access to
> your data. This is all "free" with WFP. On the other hand HTML sites
So you are proposing substitution of a sparse grammar for the richness
of the HTTP linked web?
> There are some cases where a login is required.the disadvantage of
managed many flavors of authentication, including OpenID etc.
> "HTML is based around the idea of one->many delivery of content. The
> only way you can get private or group communication on the web is on
> social networking sites.
??? not true at all. there are millions of variations of private data on
the web.
> With HTML the social-content will always be "second tire", hosted
> within another site. With wave all content, regardless of host, will
> be delivered the same way and have equal footing."
what does this mean?
functionality (e.g.renderers), by simply pointing to an external URI
> on the webpages and you need to have access to the server to do so.
OK. fine. we're connected to the net.
> This usually means complete power over the data, but it's not
> something that external developers can do. So again, you have to rely
> on what the server admins give to you.
There are established semantics for this. no problem.
> On WFP there are the robots. Anyone can develop and host them
> somewhere and every user can add bots to their waves.
> This means that more developers are able to add functionality to the
> system, and that all users have a complete freedom about what
> functionality they want into their waves.
OK. this is a special case that might exist in parallel with AR served
with other protocols
detect clients. I do believe that any AR browser needs to be able to
publish it's precise 3D location, pose and field of view so that ARweb
service providers can format the experience according to device affordances.
It seems you comments are confusing several dimensions simultaneously.
It might be helpful to narrow these discussion.
See comments interleaved:
On 5/3/10 9:51 AM, Davide Carnovale wrote:
> here are some thought on the advantages/disadvantages of WFP (wave
> federation protocol) and HTML5
markup which wil inevitably be included in AR., XMPP is an Extensible
Messaging and Presence Protocol. Shouldn't you be contrasting XMPP with
HTTP?
> - user generated content: This is easier in WFP because you don't need
> to know HTML, you don't need to have a server to host your content,
program HTML5 media
> you don't need to now tech details about granting/restriting access to
> your data. This is all "free" with WFP. On the other hand HTML sites
of the HTTP linked web?
> There are some cases where a login is required.the disadvantage of
> this, is that many websites = many logins (with some exceptions like
> openID). WFP is private, in the way it requires a login, but on the
> other hand, one login = access to all federated content.
Again, this seems completely orthoganal. Won't any AR browser have to
> openID). WFP is private, in the way it requires a login, but on the
> other hand, one login = access to all federated content.
managed many flavors of authentication, including OpenID etc.
> "HTML is based around the idea of one->many delivery of content. The
> only way you can get private or group communication on the web is on
> social networking sites.
the web.
> With HTML the social-content will always be "second tire", hosted
> within another site. With wave all content, regardless of host, will
> be delivered the same way and have equal footing."
>
> - social communication: this feature is builtin in WFP but lack
> totally on HTML
This is an Apples vs. Oranges non-argument
> - social communication: this feature is builtin in WFP but lack
> totally on HTML
>
> - adding functionality: in HTML you need to develop a plugin for the
> sw running
wrong. HTML5 = HTML+ XML and can by definition call up external
> - adding functionality: in HTML you need to develop a plugin for the
> sw running
functionality (e.g.renderers), by simply pointing to an external URI
> on the webpages and you need to have access to the server to do so.
> This usually means complete power over the data, but it's not
> something that external developers can do. So again, you have to rely
> on what the server admins give to you.
> On WFP there are the robots. Anyone can develop and host them
> somewhere and every user can add bots to their waves.
> This means that more developers are able to add functionality to the
> system, and that all users have a complete freedom about what
> functionality they want into their waves.
with other protocols
>
> - what should an "old style" browser see when pointed to AR pages:
> this is another problem that needs to be explored. Not all AR data
> fits intoa web page, so, should we take into account an alternative
> - what should an "old style" browser see when pointed to AR pages:
> this is another problem that needs to be explored. Not all AR data
> visual rendering when the data has to be displayed in a non AR-capable
> device?
This a service specific implementation of a common server capability to
> device?
detect clients. I do believe that any AR browser needs to be able to
publish it's precise 3D location, pose and field of view so that ARweb
service providers can format the experience according to device affordances.
ThomasWrobel
May 3, 2010, 4:30:13 PM5/3/10
to Open ARweb
I think I'll cover some of this as some of it seems to be
misunderstandings, not helped by some of my own quotes not being too
clear.
> > here are some thought on the advantages/disadvantages of WFP (wave
> > federation protocol) and HTML5
>
> Is this an either/or situation?HTML5 is fais d'accomplin the web display
> markup which wil inevitably be included in AR., XMPP is an Extensible
> Messaging and Presence Protocol. Shouldn't you be contrasting XMPP with
> HTTP?
Absolutely correct.
HTML5 is a way of storing information, Wave is a way of exchanging it.
However, HTML5 cant work in Wave, so its abstract key/value pairs
transmitted over WFP vs HTML5/(Other?) transmitted over HTTP.
(I assume in neither case we are talking about actual 3d geometry
inlined, however. Putting that in markup would make pages far too big.
Both Wave and HTML5 would link to 3d meshs ver HTTP or maybe FTP)
> > - user generated content: This is easier in WFP because you don't need
> > to know HTML, you don't need to have a server to host your content,
>
> This patently a false argument. Millions of people will know how to
> program HTML5 media
Thats a little unfair.
Davide said "easier".
Lots of people can code in HTML of one sort or another, certainly, but
billions know how to send an email.
> > you don't need to now tech details about granting/restriting access to
> > your data. This is all "free" with WFP. On the other hand HTML sites
>
> So you are proposing substitution of a sparse grammar for the richness
> of the HTTP linked web?
But how much of the richness of the web is transferable to real space
however?
I must admit this point I am a bit hung-up on.
Most markup, as well as the whole idea of a "hyperlink" dont seem to
mesh well with AR.
> > There are some cases where a login is required.the disadvantage of
> > this, is that many websites = many logins (with some exceptions like
> > openID). WFP is private, in the way it requires a login, but on the
> > other hand, one login = access to all federated content.
>
> Again, this seems completely orthoganal. Won't any AR browser have to
> managed many flavors of authentication, including OpenID etc.
Not really.
Under WFP you would theoretical only require one login. That login
would act very much like an OpenID in itself, with each other server
checking against your source server to authenticate you.
The only times additional logins might be needed is with banks which
would want an additional level of security.
To some extent the email analogy still applies here. You can be on a
secure mailing list only sent to a select few, but you still only use
your regular email login to see that email.
> > "HTML is based around the idea of one->many delivery of content. The
> > only way you can get private or group communication on the web is on
> > social networking sites.
>
> ??? not true at all. there are millions of variations of private data on
> the web.
And all of them use additional code, all using their own bespoke
systems incompatible with everyone else.
Would you rather exist in a world of email? or just Facebook?
Because thats quite a difference. One is a protocol for social
information exchange. Anyone can implement, any server can run, and
your certain of compatibility with everyone else.
However, if everyone needs to be on the same company's server to share
content you end up with massive hubs like Facebook.
It just doesn't seem a sensible model for a structure.
This is what scares me most, the idea of a few closed-hubs. If I want
to see my friends AR data, I need to also join that same hub. It
quickly snowballs.
> > With HTML the social-content will always be "second tire", hosted
> > within another site. With wave all content, regardless of host, will
> > be delivered the same way and have equal footing."
>
> what does this mean?
Sorry about thata, I meant that HTML/HTTP is a protocol in itself able
to exchange data, but when your dealing with social content your
submitting to additional protocols built ontop of it. Your no longer
dealing with native web protocols for anything other then display.
> > - social communication: this feature is builtin in WFP but lack
> > totally on HTML
>
> This is an Apples vs. Oranges non-argument
Why? I can certainly picture scenarios were I want to leave messages
for a friend (either geolocated or just direct). Logging into a
seperate program/site/protocol is more bother for the end user.So I do
think its relevant.
I wont argue that the comparison is Apples and Oranges. These are too
extremely different things we are comparing.
I just think the strong features of Oranges are not necessary that
useful for AR, while the strong-points of Apples are great for making
this pie.
(sorry, I'm not too good at analogy extensions ;) )
> I do believe that any AR browser needs to be able to
>publish it's precise 3D location, pose and field of view so that ARweb
>service providers can format the experience according to device affordable.
*insert privacy concern backlash here*
While I'm not that concerned about privacy myself, lots of people are
so I think you have to tread carefully.
I think clients should be able to take the data they need and display
it without giving up their precise location.
(They should have the -option- to do so, much like current map-apps on
phones, however).
--
Ok, even if we disagree, I hope the points are clear enough :)
-Thomas
misunderstandings, not helped by some of my own quotes not being too
clear.
> > here are some thought on the advantages/disadvantages of WFP (wave
> > federation protocol) and HTML5
>
> Is this an either/or situation?HTML5 is fais d'accomplin the web display
> markup which wil inevitably be included in AR., XMPP is an Extensible
> Messaging and Presence Protocol. Shouldn't you be contrasting XMPP with
> HTTP?
HTML5 is a way of storing information, Wave is a way of exchanging it.
However, HTML5 cant work in Wave, so its abstract key/value pairs
transmitted over WFP vs HTML5/(Other?) transmitted over HTTP.
(I assume in neither case we are talking about actual 3d geometry
inlined, however. Putting that in markup would make pages far too big.
Both Wave and HTML5 would link to 3d meshs ver HTTP or maybe FTP)
> > - user generated content: This is easier in WFP because you don't need
> > to know HTML, you don't need to have a server to host your content,
>
> This patently a false argument. Millions of people will know how to
> program HTML5 media
Davide said "easier".
Lots of people can code in HTML of one sort or another, certainly, but
billions know how to send an email.
> > you don't need to now tech details about granting/restriting access to
> > your data. This is all "free" with WFP. On the other hand HTML sites
>
> So you are proposing substitution of a sparse grammar for the richness
> of the HTTP linked web?
however?
I must admit this point I am a bit hung-up on.
Most markup, as well as the whole idea of a "hyperlink" dont seem to
mesh well with AR.
> > There are some cases where a login is required.the disadvantage of
> > this, is that many websites = many logins (with some exceptions like
> > openID). WFP is private, in the way it requires a login, but on the
> > other hand, one login = access to all federated content.
>
> Again, this seems completely orthoganal. Won't any AR browser have to
> managed many flavors of authentication, including OpenID etc.
Under WFP you would theoretical only require one login. That login
would act very much like an OpenID in itself, with each other server
checking against your source server to authenticate you.
The only times additional logins might be needed is with banks which
would want an additional level of security.
To some extent the email analogy still applies here. You can be on a
secure mailing list only sent to a select few, but you still only use
your regular email login to see that email.
> > "HTML is based around the idea of one->many delivery of content. The
> > only way you can get private or group communication on the web is on
> > social networking sites.
>
> ??? not true at all. there are millions of variations of private data on
> the web.
systems incompatible with everyone else.
Would you rather exist in a world of email? or just Facebook?
Because thats quite a difference. One is a protocol for social
information exchange. Anyone can implement, any server can run, and
your certain of compatibility with everyone else.
However, if everyone needs to be on the same company's server to share
content you end up with massive hubs like Facebook.
It just doesn't seem a sensible model for a structure.
This is what scares me most, the idea of a few closed-hubs. If I want
to see my friends AR data, I need to also join that same hub. It
quickly snowballs.
> > With HTML the social-content will always be "second tire", hosted
> > within another site. With wave all content, regardless of host, will
> > be delivered the same way and have equal footing."
>
> what does this mean?
to exchange data, but when your dealing with social content your
submitting to additional protocols built ontop of it. Your no longer
dealing with native web protocols for anything other then display.
> > - social communication: this feature is builtin in WFP but lack
> > totally on HTML
>
> This is an Apples vs. Oranges non-argument
for a friend (either geolocated or just direct). Logging into a
seperate program/site/protocol is more bother for the end user.So I do
think its relevant.
I wont argue that the comparison is Apples and Oranges. These are too
extremely different things we are comparing.
I just think the strong features of Oranges are not necessary that
useful for AR, while the strong-points of Apples are great for making
this pie.
(sorry, I'm not too good at analogy extensions ;) )
> I do believe that any AR browser needs to be able to
>publish it's precise 3D location, pose and field of view so that ARweb
*insert privacy concern backlash here*
While I'm not that concerned about privacy myself, lots of people are
so I think you have to tread carefully.
I think clients should be able to take the data they need and display
it without giving up their precise location.
(They should have the -option- to do so, much like current map-apps on
phones, however).
--
Ok, even if we disagree, I hope the points are clear enough :)
-Thomas
Mike Liebhold
May 3, 2010, 4:58:39 PM5/3/10
to open...@googlegroups.com, ThomasWrobel
On 5/3/10 1:30 PM, ThomasWrobel wrote:
I meant that HTML/HTTP is a protocol in itself
errr..... not one protocol. two discrete concepts.
according to wikipedia
[ http://en.wikipedia.org/wiki/HTML]
HTML= HyperText Markup Language, is the predominant markup language for web pages. It provides a means to create structured documents by denoting structural semantics for text such as headings, paragraphs, lists etc as well as for links, quotes, and other items. It allows images and objects to be embedded and can be used to create interactive forms.
and
http://en.wikipedia.org/wiki/Http
HTTP = Hypertext Transfer Protocol (HTTP) is an Application Layer protocol for distributed, collaborative, hypermedia information systems.[1]... a request-response standard typical of client-server computing. In HTTP, web browsers or spiders typically act as clients, while an application running on the computer hosting the web site acts as a server.
---
You are really stirring up muddy water here., it is going to be impossible to engage in productive dialog if we can't keep these concepts clear, separate along with other - distinct - often orthoganal concepts too.
according to wikipedia
[ http://en.wikipedia.org/wiki/HTML]
HTML= HyperText Markup Language, is the predominant markup language for web pages. It provides a means to create structured documents by denoting structural semantics for text such as headings, paragraphs, lists etc as well as for links, quotes, and other items. It allows images and objects to be embedded and can be used to create interactive forms.
and
http://en.wikipedia.org/wiki/Http
HTTP = Hypertext Transfer Protocol (HTTP) is an Application Layer protocol for distributed, collaborative, hypermedia information systems.[1]... a request-response standard typical of client-server computing. In HTTP, web browsers or spiders typically act as clients, while an application running on the computer hosting the web site acts as a server.
---
You are really stirring up muddy water here., it is going to be impossible to engage in productive dialog if we can't keep these concepts clear, separate along with other - distinct - often orthoganal concepts too.
Anselm Hook
May 3, 2010, 5:12:43 PM5/3/10
to open...@googlegroups.com, open...@googlegroups.com, ThomasWrobel
I think also sometimes people conflates the current wave ui as presented by google wave with the underlying wave protocol in the same way.
Sent from my iPhone
Davide Carnovale
May 3, 2010, 5:41:22 PM5/3/10
to Mike Liebhold, open...@googlegroups.com
Nice to see the discussion actually taking place here.
Sorry about not being clear as i wanted, below are some clarifications (or at least i hope so)
Sorry about not being clear as i wanted, below are some clarifications (or at least i hope so)
2010/5/3 Mike Liebhold <m...@well.com>
David,
It seems you comments are confusing several dimensions simultaneously. It might be helpful to narrow these discussion.
See comments interleaved:Is this an either/or situation?HTML5 is fais d'accomplin the web display markup which wil inevitably be included in AR., XMPP is an Extensible Messaging and Presence Protocol. Shouldn't you be contrasting XMPP with HTTP?
On 5/3/10 9:51 AM, Davide Carnovale wrote:
here are some thought on the advantages/disadvantages of WFP (wave federation protocol) and HTML5
Actually wave is based on xmpp but adds something, so that's why i used wave
This patently a false argument. Millions of people will know how to program HTML5 media
- user generated content: This is easier in WFP because you don't need to know HTML, you don't need to have a server to host your content,
Totally disagree with this. My mom can insert an image into a forum with a wysiwyg editor, but has no clue about what the tag <img> is.
This means that AR should rely on what the web server is offering to the user; and many webservers = many different tools to learn.
This means that AR should rely on what the web server is offering to the user; and many webservers = many different tools to learn.
So you are proposing substitution of a sparse grammar for the richness of the HTTP linked web?
you don't need to now tech details about granting/restriting access to your data. This is all "free" with WFP. On the other hand HTML sites
There are some cases where a login is required.the disadvantage of this, is that many websites = many logins (with some exceptions like openID). WFP is private, in the way it requires a login, but on the other hand, one login = access to all federated content.
Again, this seems completely orthoganal. Won't any AR browser have to managed many flavors of authentication, including OpenID etc.
For the same reason why openID exists: users are bothered to have many logins for many sites. the capabilities of federation in this regard are great for me. On the other hand, if you want your data to be private you can just not federate your server.
??? not true at all. there are millions of variations of private data on the web.
"HTML is based around the idea of one->many delivery of content. The only way you can get private or group communication on the web is on social networking sites.
what does this mean?
With HTML the social-content will always be "second tire", hosted within another site. With wave all content, regardless of host, will be delivered the same way and have equal footing."
This is an Apples vs. Oranges non-argument
- social communication: this feature is builtin in WFP but lack totally on HTML
wrong. HTML5 = HTML+ XML and can by definition call up external functionality (e.g.renderers), by simply pointing to an external URI
- adding functionality: in HTML you need to develop a plugin for the sw running
OK. fine. we're connected to the net.
on the webpages and you need to have access to the server to do so.
you totally missed the point here, my bad, sorry. What i meant is: if you want to change the content of a webpage that is already out there, you need access to the webserver hosting the pages. Within the years we've developed some workaround to this, like dynamic pages, but again, you're restricted to what the website allows you to do. You can add comments on wordpress or start a discussion in a forum, but you can't modify your friends post unless you know they're login infos.
There are established semantics for this. no problem.
This usually means complete power over the data, but it's not something that external developers can do. So again, you have to rely on what the server admins give to you.
OK. this is a special case that might exist in parallel with AR served with other protocols
On WFP there are the robots. Anyone can develop and host them somewhere and every user can add bots to their waves.
This means that more developers are able to add functionality to the system, and that all users have a complete freedom about what functionality they want into their waves.
- what should an "old style" browser see when pointed to AR pages: this is another problem that needs to be explored. Not all AR data fits intoa web page, so, should we take into account an alternative visual rendering when the data has to be displayed in a non AR-capable device?
This a service specific implementation of a common server capability to detect clients. I do believe that any AR browser needs to be able to publish it's precise 3D location, pose and field of view so that ARweb service providers can format the experience according to device affordances.
Can you clarify this a bit please?
Mike Liebhold
May 3, 2010, 6:13:59 PM5/3/10
to Davide Carnovale, open...@googlegroups.com
On 5/3/10 2:41 PM, Davide Carnovale wrote:
2010/5/3 Mike Liebhold <m...@well.com>
Shouldn't you be contrasting XMPP with HTTP?
Actually wave is based on xmpp but adds something, so that's why i used wave
The question remains. why are you comparing a presence protocol with a
display markup? If you are talking about wave display protocols, what
are they, independent of xmpp?
Millions of people will know how to program HTML5 media
Totally disagree with this. My mom can insert an image into a forum with a wysiwyg editor, but has no clue about what the tag <img> is.This means that AR should rely on what the web server is offering to the user; and many webservers = many different tools to learn.
This is a non-sequitar. The logic does not follow. Different tools and different servers do not map. It is easy to imagine similar data from many different servers, or multiple types of data from one server.
There are some cases where a login is required.the disadvantage of this, is that many websites = many logins (with some exceptions like openID). WFP is private, in the way it requires a login, but on the other hand, one login = access to all federated content.
Again, this seems completely orthoganal. Won't any AR browser have to managed many flavors of authentication, including OpenID etc.
For the same reason why openID exists: users are bothered to have many logins for many sites. the capabilities of federation in this regard are great for me. On the other hand, if you want your data to be private you can just not federate your server.
Again, federation, authentication, logins, privacy are all tangential
to both display and data transfer protocols. I understand that your
concept of wave AR concatonates all of these into one service, but
pragamatically, if you if you and your cohort are able to build and AR
wave experience, This will not in any way inhibit people from building
and AR web based on html5, GML, nd HTTP, and a garden variety of
authenticated identities.
If you are actually able to build it, your ARwave app and services will exist in parallel NOT instead of an ARweb built on other protocols.
If you are actually able to build it, your ARwave app and services will exist in parallel NOT instead of an ARweb built on other protocols.
What i meant is: if you want to change the content of a webpage that is already out there, you need access to the webserver hosting the pages. Within the years we've developed some workaround to this, like dynamic pages, but again, you're restricted to what the website allows you to do.
Not necessarily, there are lots of examples of rich client side
interaction ( independent of a server) built on AJAX/JSON etc. e.g.
Lively Kernel - a complete OS running in a modern browser. check it
out: http://labs.oracle.com/projects/lively/
I do believe that any AR browser needs to be able to publish it's precise 3D location, pose and field of view so that ARweb service providers can format the experience according to device affordances.
Can you clarify this a bit please?
This is really a separate discussion that I'll take offline to another
thread - later.
- M.
- M.
Mike Liebhold
May 3, 2010, 6:51:11 PM5/3/10
to Thomas Wrobel, open...@googlegroups.com
On 5/3/10 3:34 PM, Thomas Wrobel wrote:
> I believe the need to show some data selectively to only a few people
> is a critical one, and without this built into a standard protocol,
> people will be forced to turn to a 3rd party sites,
How does this follow? Magic cookies (standard protocol) were invented,
precisely to be able to provide a custom experience for a user, if
that's what a service designer intends.
> and (without even a equivalent of email) people would quickly all be
> forced to join the same one. Theres a real danger of too much power
> falling into a one company's hand that I want to avoid.
This is really hard to understand. What are you talking about? And, how
does any of this have anything to do with corporate power?
> At the very least AR needs its equivalent email*. A way
> to personally geolocate data and share it with others not on the
> same company's server.
h'mm.. I'm trying hard to understand the connection of an AR email,
geolocation, and company servers - these exisit is completely separate
universes.
> I believe the need to show some data selectively to only a few people
> is a critical one, and without this built into a standard protocol,
> people will be forced to turn to a 3rd party sites,
How does this follow? Magic cookies (standard protocol) were invented,
precisely to be able to provide a custom experience for a user, if
that's what a service designer intends.
> and (without even a equivalent of email) people would quickly all be
> forced to join the same one. Theres a real danger of too much power
> falling into a one company's hand that I want to avoid.
This is really hard to understand. What are you talking about? And, how
does any of this have anything to do with corporate power?
> At the very least AR needs its equivalent email*. A way
> to personally geolocate data and share it with others not on the
> same company's server.
h'mm.. I'm trying hard to understand the connection of an AR email,
geolocation, and company servers - these exisit is completely separate
universes.
mez breeze
May 3, 2010, 6:55:39 PM5/3/10
to open...@googlegroups.com, Thomas Wrobel
....[lobbing ARML into the mix might get me synthetically-punched b4 i even contribute an intro;) http://www.openarml.org/ ]....
--
Reality Engineer>
Synthetic Environment Strategist>
Game[r + ] Theorist.
::http://unhub.com/netwurker ::
Reality Engineer>
Synthetic Environment Strategist>
Game[r + ] Theorist.
::http://unhub.com/netwurker ::
Mike Liebhold
May 3, 2010, 7:01:23 PM5/3/10
to open...@googlegroups.com, mez breeze, Thomas Wrobel
On 5/3/10 3:55 PM, mez breeze wrote:
> ....[lobbing ARML into the mix... http://www.openarml.org/ ]....
ARML is an undisclosed variation of KML that might be interesting to
discuss, if the proponents actually supply sufficent detail of what
they're proposing. So far, there's very little subtance to the idea of
an Augmented Reality Markup. It is precisely that half-start that
motivates some of us to take our discussions here.
> ....[lobbing ARML into the mix... http://www.openarml.org/ ]....
ARML is an undisclosed variation of KML that might be interesting to
discuss, if the proponents actually supply sufficent detail of what
they're proposing. So far, there's very little subtance to the idea of
an Augmented Reality Markup. It is precisely that half-start that
motivates some of us to take our discussions here.
J. Andrew Rogers
May 3, 2010, 7:55:50 PM5/3/10
to open...@googlegroups.com
The basic implementation model of hyperlink markup is pretty broken
for AR short of a wholesale reimplementation of the concept of
hyperlinks. In AR, hyperlinks are not traditional document structures,
they are views and projections through literal metric spaces; you
could encode that as a document structure, but the impedance mismatch
would be very high. What has not been established is the underlying
representation assumptions we should be using that will be driving a
lot of real-world engineering decisions as a practical matter.
At a basic level, you are looking for intersections between
projections of metric spaces. You have the universe of AR data that
maps to reality, a projected subset of which you actually care about
(i.e. I don't subscribe to every RSS feed on the Internet). It is a
non-trivial relation.
On top of that, if you look at that projection as a virtual model of
the state of the planet that is your AR context, you still need to
manage and communicate the dynamic projection through that model that
you should actual be interacting with.
Unlike traditional document graph models, this is not a simple scalar
graph. It is a dynamic projection through a dynamic projection in a
high-dimensionality metric space. There are many ways this can be
implemented at tiny scales but at real Internet scales it opens a huge
can of computer science worms that should be thoughtfully navigated.
We can't even scale graphs unless we treat them like documents (lose
analytical capability but gain shardability) and that trick really
won't work well here even if AR (severely) limited itself to that kind
of model because a dynamic hyperlink model in an AR universe is not
amenable to heavy-handed dimensional reduction.
Not only does an AR protocol have to scale, the implied data model
needs to scale as well and that data model should inform many details
of the protocol.
--
J. Andrew Rogers
for AR short of a wholesale reimplementation of the concept of
hyperlinks. In AR, hyperlinks are not traditional document structures,
they are views and projections through literal metric spaces; you
could encode that as a document structure, but the impedance mismatch
would be very high. What has not been established is the underlying
representation assumptions we should be using that will be driving a
lot of real-world engineering decisions as a practical matter.
At a basic level, you are looking for intersections between
projections of metric spaces. You have the universe of AR data that
maps to reality, a projected subset of which you actually care about
(i.e. I don't subscribe to every RSS feed on the Internet). It is a
non-trivial relation.
On top of that, if you look at that projection as a virtual model of
the state of the planet that is your AR context, you still need to
manage and communicate the dynamic projection through that model that
you should actual be interacting with.
Unlike traditional document graph models, this is not a simple scalar
graph. It is a dynamic projection through a dynamic projection in a
high-dimensionality metric space. There are many ways this can be
implemented at tiny scales but at real Internet scales it opens a huge
can of computer science worms that should be thoughtfully navigated.
We can't even scale graphs unless we treat them like documents (lose
analytical capability but gain shardability) and that trick really
won't work well here even if AR (severely) limited itself to that kind
of model because a dynamic hyperlink model in an AR universe is not
amenable to heavy-handed dimensional reduction.
Not only does an AR protocol have to scale, the implied data model
needs to scale as well and that data model should inform many details
of the protocol.
--
J. Andrew Rogers
Tish Shute
May 3, 2010, 11:09:33 PM5/3/10
to open...@googlegroups.com
Hi Andrew - you encapsulate so many of the great challenges of AR here. I am very excited to hear from you. At the same time I was reading your post, in an interesting synchronicity, Anselm just forwarded me some of the thoughts of Jim Spohrer on AR (I very much hope Jim Spohrer will join this group soon). He is:
"less interested in the data visualization aspects of AR these day (though they are still important challenges there) and much more interested in an environment for combining models of the world, in a way that models can be rapidly improved."
Seems very relevant to the words of wisdom you end your post with!
"Not only does an AR protocol have to scale, the implied data model
needs to scale as well and that data model should inform many details
of the protocol."
Jim Spohrer also forwarded a link to, perhaps, the most ambitious data modeling project ever, which I guess is also the mother of all use cases for AR!
http://www.technologyreview.com/blog/arxiv/25126/?a=f
"The 'Living Earth Simulator' will mine economic, environmental and health data to create a model of the entire planet in real time."
The article describes a kind of a "google earth on steriods" - an augmented virtuality rather than mobile augmented reality. But predictive modeling in the hyperlocal view of mobile AR would be part of this great vision too, I would hope.
Anselm Hook (also in this group) is a big inspiration for me on the potential role for AR in "bridging the schism between humanity and the ecosystem," so I look forward to some interesting discussion to come!
best,
Tish
--
Tish Shute
Founder
Ugotrade
http://www.ugotrade.com
Register for Augmented Reality Event at http://augmentedrealityevent.com/register
tish....@gmail.com
@tishshute
skype tish.shute
+1 646 753 0539
"less interested in the data visualization aspects of AR these day (though they are still important challenges there) and much more interested in an environment for combining models of the world, in a way that models can be rapidly improved."
Seems very relevant to the words of wisdom you end your post with!
"Not only does an AR protocol have to scale, the implied data model
needs to scale as well and that data model should inform many details
of the protocol."
http://www.technologyreview.com/blog/arxiv/25126/?a=f
"The 'Living Earth Simulator' will mine economic, environmental and health data to create a model of the entire planet in real time."
The article describes a kind of a "google earth on steriods" - an augmented virtuality rather than mobile augmented reality. But predictive modeling in the hyperlocal view of mobile AR would be part of this great vision too, I would hope.
Anselm Hook (also in this group) is a big inspiration for me on the potential role for AR in "bridging the schism between humanity and the ecosystem," so I look forward to some interesting discussion to come!
best,
Tish
Tish Shute
Founder
Ugotrade
http://www.ugotrade.com
Register for Augmented Reality Event at http://augmentedrealityevent.com/register
tish....@gmail.com
@tishshute
skype tish.shute
+1 646 753 0539
Christian Willmes
May 4, 2010, 2:39:48 AM5/4/10
to open...@googlegroups.com
Hello,
I am in favor of an more practical approach. More learnig by doing, then
learning a lot about how do it without actually doing it. So this ARML
looks interesting to me. Don't get me wrong, I am absolutely pro
thinking about how to do something right, but I think an iterative
approach starting with some rather basic concept and then extend and
emerge to higher complexity is leading faster to success. It is also
about how easy adaptable this tech will be for the end user, also for
the providing and sharing of content side.
I am thinking about some simple standardised basics to provide AR in
some sense, which should be extendable in complexity for applications
which may faciltitate this higher complexity.
In general it is just some geometry connected to some content. Which is
for example a Placemark defined by KML, this can be extended with
orentation parameters and other complexity. But the basis is a geometry
and content.
Interactivity is implemented like for web2.0 apps, by updating the
content dymanicaly serverside, manipulating it clientside and combining
both.
In my vison, the content providers (this can also be every user (every
human being), say with some freely available webserver space at some
large company which offers that to spy your behaviour ;)), host their AR
enteties (Placemarks) by them self. Then one "registers" the content in
some sorts of feeds/repositories (RSS like, twitter like,anything like
that). Sophisticated technology to filter this sort of content will
emerge, or already exists... Then the user can define some set of
filters in her AR browser and add his "feeds" to augment her realty...
providing such feeds with good/valuable content will be a good buissines
I think...
This is already in some sense implemented in the various emerging
smartphone apps like layar, wikitude etc.. I think the biggest hurdle
for now is the end user device technology, which is in a
smartphone/handheld not perfect for AR I think. The most fun of AR will
emerge, if you can see/percieve the markups instantly without your
smartphone/handheld is telling you to point it in some direction to see
"something", you have to consume AR "en passe" you don't have to intend
to look around for AR to much... I think. And also... to provide a realy
mature technology you may need to have an example of how you can't
actually do it by proving how it is wrong, but I can't see how this
simple approach of ARML for example is wrong, for now...
regards,
Christian
Mike Liebhold schrieb:
I am in favor of an more practical approach. More learnig by doing, then
learning a lot about how do it without actually doing it. So this ARML
looks interesting to me. Don't get me wrong, I am absolutely pro
thinking about how to do something right, but I think an iterative
approach starting with some rather basic concept and then extend and
emerge to higher complexity is leading faster to success. It is also
about how easy adaptable this tech will be for the end user, also for
the providing and sharing of content side.
I am thinking about some simple standardised basics to provide AR in
some sense, which should be extendable in complexity for applications
which may faciltitate this higher complexity.
In general it is just some geometry connected to some content. Which is
for example a Placemark defined by KML, this can be extended with
orentation parameters and other complexity. But the basis is a geometry
and content.
Interactivity is implemented like for web2.0 apps, by updating the
content dymanicaly serverside, manipulating it clientside and combining
both.
In my vison, the content providers (this can also be every user (every
human being), say with some freely available webserver space at some
large company which offers that to spy your behaviour ;)), host their AR
enteties (Placemarks) by them self. Then one "registers" the content in
some sorts of feeds/repositories (RSS like, twitter like,anything like
that). Sophisticated technology to filter this sort of content will
emerge, or already exists... Then the user can define some set of
filters in her AR browser and add his "feeds" to augment her realty...
providing such feeds with good/valuable content will be a good buissines
I think...
This is already in some sense implemented in the various emerging
smartphone apps like layar, wikitude etc.. I think the biggest hurdle
for now is the end user device technology, which is in a
smartphone/handheld not perfect for AR I think. The most fun of AR will
emerge, if you can see/percieve the markups instantly without your
smartphone/handheld is telling you to point it in some direction to see
"something", you have to consume AR "en passe" you don't have to intend
to look around for AR to much... I think. And also... to provide a realy
mature technology you may need to have an example of how you can't
actually do it by proving how it is wrong, but I can't see how this
simple approach of ARML for example is wrong, for now...
regards,
Christian
Mike Liebhold schrieb:
Christine Perey
May 4, 2010, 9:09:22 AM5/4/10
to open...@googlegroups.com, Martin Lechner, Philipp Breuss
Hello,
By way of this e-mail I'm introducing Martin Lechner and Philipp Breuss
to the list and letting them know of the group's interest in the details
of ARML. Martin is CTO and Philipp is CEO of Mobilizy, the architects
and proposers of the ARML.
Martin and Philipp, there is a group of over 70 people (at last count)
who are exploring possible solutions for AR challenges, including ARML.
If you have not already done so, we hope you will join the OpenARWeb
discussion forum on Google Groups.
--
Christine
Spime Wrangler
cpe...@perey.com
mobile +41 79 436 68 69
VoIP (from US) +1 (617) 848-8159
Skype (from anywhere) Christine_Perey
By way of this e-mail I'm introducing Martin Lechner and Philipp Breuss
to the list and letting them know of the group's interest in the details
of ARML. Martin is CTO and Philipp is CEO of Mobilizy, the architects
and proposers of the ARML.
Martin and Philipp, there is a group of over 70 people (at last count)
who are exploring possible solutions for AR challenges, including ARML.
If you have not already done so, we hope you will join the OpenARWeb
discussion forum on Google Groups.
--
Christine
Spime Wrangler
cpe...@perey.com
mobile +41 79 436 68 69
VoIP (from US) +1 (617) 848-8159
Skype (from anywhere) Christine_Perey
J. Andrew Rogers
May 4, 2010, 1:03:15 PM5/4/10
to open...@googlegroups.com
On Mon, May 3, 2010 at 8:09 PM, Tish Shute <tish....@gmail.com> wrote:
>
> Jim Spohrer also forwarded a link to, perhaps, the most ambitious data
> modeling project ever, which I guess is also the mother of all use cases for
> AR!
>
> http://www.technologyreview.com/blog/arxiv/25126/?a=f
>
> "The 'Living Earth Simulator' will mine economic, environmental and health
> data to create a model of the entire planet in real time."
Tish,
>
> Jim Spohrer also forwarded a link to, perhaps, the most ambitious data
> modeling project ever, which I guess is also the mother of all use cases for
> AR!
>
> http://www.technologyreview.com/blog/arxiv/25126/?a=f
>
> "The 'Living Earth Simulator' will mine economic, environmental and health
> data to create a model of the entire planet in real time."
A number of well-funded organizations have been attempting to do this
already, albeit with less publicity. While the vision is compelling,
there are very good reasons no one has produced anything remotely like
a viable implementation even with large budgets and a reputation for
scalable engineering. I'm not sanguine about the above project unless
they are employing very novel technology.
In my experience, these projects have a common trajectory. Early ideas
use conventional large-scale web technologies but people quickly
realize that those technologies aren't designed for this use case. So
they do a purpose-built design, prototype it, and quickly realize that
there is a large computer science gap between what they know how to
build and what needs to be built. It turns out to be far more
difficult to do than it looks like it should be upon casual
inspection.
> The article describes a kind of a "google earth on steriods" - an augmented
> virtuality rather than mobile augmented reality. But predictive modeling in
> the hyperlocal view of mobile AR would be part of this great vision too, I
> would hope.
implemented one, you've effectively implemented the other. That is why
this is such a transformative technology; solving one of these
problems solves a wide range of other interesting technology problems.
--
J. Andrew Rogers
ThomasWrobel
May 10, 2010, 9:45:43 AM5/10/10
to Open ARweb
> On 5/3/10 3:34 PM, Thomas Wrobel wrote:> I believe the need to show some data selectively to only a few people
> > is a critical one, and without this built into a standard protocol,
> > people will be forced to turn to a 3rd party sites,
>
> How does this follow? Magic cookies (standard protocol) were invented,
> precisely to be able to provide a custom experience for a user, if
> that's what a service designer intends.
(let alone do it as easy as posting an email)
You cant expect each individual person to make their own web-page and
authentication system every time they want to share data privately
with others!
>> and (without even a equivalent of email) people would quickly all be
>> forced to join the same one. Theres a real danger of too much power
>> falling into a one company's hand that I want to avoid.
>This is really hard to understand. What are you talking about? And, how
>does any of this have anything to do with corporate power?
trying to send a message to just 5 specific people online.
Your trying to give them, say, 1 page of information.
How would you do it?
My statement is that without email/im protocols the only way to send a
message *only to specific people-* is to use bespoke social systems
such as Facebook.
Everyone has to be on that company's system in order to authentic the
identity's and let the people see the page.
(You could alternatively, I guess, buy a domain, host a FTP, and
publish the file only to the people you want to send the page too, but
this is hardly a practical mass solution.)
>h'mm.. I'm trying hard to understand the connection of an AR email,
>geolocation, and company servers - these exisit is completely separate
>universes.
My proposition is that without a standard way to publish geolocated
data to just specific people, you will almost certainly end up with
one dominating company doing exactly that job.
Email is merely an analogy I am using it to show a need for the
private exchange of information. - a need I see direct equivalents of
with AR.
Fundamentally Email is a protocol allowing us to share data between
individuals, but we dont all need to be on the same server. This is
*really* critical.
If everyone on Hotmail could only send emails to other Hotmail users
it would be awful no? Ditto for Gmail, Yahoo whatever.
Yet that's exactly what you would get if there wasn't a standardised
inter-server protocol.
It would inevitably lead to almost everyone migrating to the same
(most popular) company's server. You would have to in order to
communicate with most other people.
Likewise, without a standard inter-server method to exchange personal
geolocated data with AR, I believe this would lead to the exact same
thing.
I hope I've explained well enough why you need standard protocols for
private/group data.
Now, If your arguing you don't see a need for private geolocated data
at all, then thats another discussion really. I can personally think
of many use-case's. (most of which arnt professional, but rather on
the family/friends level)
Or, if you think theres no need for a new protocol for this, and
actual email,various IM and IRC protocols could all be used to
exchange geolocated data, then Id agree, but Id argue those old
protocols are hardly ideal.
I hope Ive made my argument more clear. I suspect we are talking
somewhat at cross-purpose's because I think a lot of what I'm saying
is fairly obvious.
ThomasWrobel
May 10, 2010, 10:30:21 AM5/10/10
to Open ARweb
> Again, federation, authentication, logins, privacy are all tangential to
> both display and data transfer protocols. I understand that your
> concept of wave AR concatonates all of these into one service, but
> pragamatically, if you if you and your cohort are able to build and AR
> wave experience, This will not in any way inhibit people from building
> and AR web based on html5, GML, nd HTTP, and a garden variety of
> authenticated identities.
data itself.
In that regard its tangential, and, in fact, pretty* neutral to the
data itself. (be it markup based, individual 3d models, or even just a
geolocated bit of sound).
However, to wholesale dismiss it as merely "another way to get to the
same data" is wrong. Mainly because some of the main problems of ar
content delivery haven't really been considered yet, and wave can play
quite a good role in these.
As part of the open-ar web solution, there needs to be a way for
clients to know what 3d models to show at a location. This isnt just a
mater of tieing something to a location - you also have to have a
method to get that physical-hyperlink information to the clients.
Logging onto a new webpage each time you walk down a few streets is
obviously impractical.
As is having huuuuuggggeee webpages listing thousands (or tens of
thousands) of 3d models on one topic in a city. (and certainly putting
them in the same download would itself be crazy).
You could of course make the browser tell the server where it is, and
then the server delivers the customised list of local data. I guess
this is what your thinking. But then your moving away from a standard
web-server. Custom-server side code would be needed to form these
lists based on client input. And if your doing this for each connected
client; Why return the data as a webpage at all? Why not get the
server to deliver the list straight to the client? (using JSON,
Protobuffers, or...umm...XMPP....)
WFP would could quite some way to being a replacement for these "pages
of links". It would be a way for a server to communicate to the
browser in a more sensible direct fashion for this sort of content.
(rather then dividing it up into webpages, or running a AJAX code
within a page, only for the browser to keep checking the page as the
Dom updates...).
> This will not in any way inhibit people from building
> and AR web based on html5, GML, nd HTTP, and a garden variety of
> authenticated identities.
3d data and doing what they like with it....neither will any other
standard. (nor should they).
However, people would not be able to access private or group content
on those waves. Specifically inline text information would be
completely invisible outside the wave system. (unless someone makes a
special wave-browser, or wave-bot to post that data back out....but
even that would just be the public data).
Using wave as way to deliver content to the browser (and to deliver
content back into the system), seems to cover a lot of the
transformation and delivery requirements of what a open ar web would
need.
---
*I say pretty natural, I think its more practical for smaller lumps of
data to be located separately, rather then massive scenes in one file.
But this is really an optimisation topic more then anything else. More
a question of "good practice" rather then what can be done.
Smaller chucks of data would allow server-side movement, and smoother
streaming, however. (less likely to notice things "popping into
view").
ThomasWrobel
May 10, 2010, 10:39:02 AM5/10/10
to Open ARweb
On May 3, 11:12 pm, Anselm Hook <ans...@gmail.com> wrote:
> I think also sometimes people conflates the current wave ui as
> presented by google wave with the underlying wave protocol in the same
> way.
Google didn't do such a good job at explaining themselves.
It doesn't help matters that the protocol, their client, and even a
type of content division within the protocol are all called "Wave".
Trying to explain WFP to people inevitably leads to poor analogy's.
Ive kinda stuck with using email, but I'm aware it isn't particularly
good. In fact, it really only applies to some aspects of the end user
experience. Internally it couldn't be more different.
Email delivers and duplicates all its content outwards to different
servers as its exchanged.
Wave pulls authenticated people from different servers to the same
source content and thus is vastly more efficient for large pieces of
data.
(So a message sent to 500 people, caches aside, would still only have
1 copy of it).
One advantages with this is spam would use far less bandwidth. A
message to 500,000 people on wave doesn't use up much more bandwidth
then just a message to 1.
-
So, yeah, looking for a good way to explain WFP is always a
challenge.
Reply all
Reply to author
Forward
0 new messages