Yes, that was the design. If requestFeature() is introduced, feature
is basically useless.
Not necessarily. There can be different security aspects for both.
The basic idea is to make requestFeature() also to be a feature.
Thanks.
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452
Ok, that makes sense; but I have serious doubts anyone will implement that.
Why?
You mean because it would not sell, because it is bad by design or any other
reason?
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail:
2009/6/9 Anne van Kesteren ann...@opera.com:
On Tue, 09 Jun 2009 01:38:14 +0200, Marcos Caceres marc...@opera.com wrote:
On 6/8/09 11:20 PM, Anne van Kesteren wrote:
On Mon, 08 Jun 2009 20:34:19 +0200, Marcos Caceresmarc...@opera.com
wrote:
Yes, that was the design. If requestFeature() is
On Tue, 09 Jun 2009 11:32:49 +0200, Marcos Caceres marc...@opera.com wrote:
Like I said, as far as WebApps is concerned requestFeature() does not
exists. What I meant was the requestFeature() undermines feature
without addressing the security issues.
I'm getting more and more confused. You
On 6/9/09 11:58 AM, Anne van Kesteren wrote:
On Tue, 09 Jun 2009 11:32:49 +0200, Marcos Caceresmarc...@opera.com wrote:
Like I said, as far as WebApps is concerned requestFeature() does not
exists. What I meant was the requestFeature() underminesfeature
without addressing the security
On Tue, Jun 9, 2009 at 10:19 AM, Marcin
Hanclikmarcin.hanc...@access-company.com wrote:
Ok, that makes sense; but I have serious doubts anyone will implement that.
Why?
You mean because it would not sell, because it is bad by design or any other
reason?
It's a bad design, IMO. However, we
Making a static declaration of a feature to indicate to the UA which
APIs to make available to a widget is already used in existing widget
and gadget implementations; requestFeature() isn't.
For example, here is the definition used by Google, and implemented in
Shindig:
Gadget Features.
2009/6/2 Jonas Sicking jo...@sicking.cc:
On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
Hi Scott,
In BONDI we have discussed the (has/request)Feature() for some time.
http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf,
2009/6/3 Marcin Hanclik marcin.hanc...@access-company.com:
Hi Scott,
I can see the UC for requestFeature, though its not something we'd
ever expect to use - we'd stick to just static feature declarations,
as we have no way of injecting scripts into instances after they've
already launched.
2009/6/3 Marcin Hanclik marcin.hanc...@access-company.com:
Hi Marcos,
requestFeature() from BONDI 1.0 is an asynchronous API that follows API
design pattern:
http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.html#asynchronicity
requestFeature() is described in detail in:
2009/6/4 Scott Wilson scott.bradley.wil...@gmail.com:
Security is on UC; another is resource use. If the UA only needs to inject
the modules needed by a Widget this can have a positive impact on downloading
and processing Widgets.
For example, if you have a lot of optional features, each of
On 6/8/09 11:20 PM, Anne van Kesteren wrote:
On Mon, 08 Jun 2009 20:34:14 +0200, Marcos Caceresmarc...@opera.com wrote:
I still have no clue what requestFeature() does/means. The again, I
have not read the Bondi spec regarding that.
On Mon, 08 Jun 2009 20:34:19 +0200, Marcos
Hi Scott,
If a Widget requires shared state and participant features (e.g.
Google Wave), then we inject our reverse-AJAX JS, which triggers
either polling, comet, or piggyback synching (depending on server
configuration). So we wouldn't want to do this for every widget,
especially when many of
On Wed, Jun 3, 2009 at 3:16 AM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
Hi Jonas,
requestFeature() is mainly (still debated, though) for websites, i.e. online
content where the feature is not present.
feature is for packaged widgets only.
Ah, so requestFeature() is a BONDI
Security is on UC; another is resource use. If the UA only needs to
inject the modules needed by a Widget this can have a positive impact
on downloading and processing Widgets.
For example, if you have a lot of optional features, each of which is
another 12k of injected JS... well, you
Yes, one of the differences between feature and requestFeature() is the time
when the actual API gets available.
What is the automatic polling?
Do you assume that the loaded feature is initialized by a kind of onLoad
method?
Thanks.
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel:
We inject JS into the head of the Widget HTML, including the Widget
API object, before sending it to the client browser; it automatically
initializes itself.
If a Widget requires shared state and participant features (e.g.
Google Wave), then we inject our reverse-AJAX JS, which triggers
We inject JS into the head of the Widget HTML, including the Widget
API object, before sending it to the client browser; it automatically
initializes itself.
As for me this is just one of the possible implementations and the spec should
not mandate how the additional API is made available.
The
Hi Scott,
I can see the UC for requestFeature, though its not something we'd
ever expect to use - we'd stick to just static feature declarations,
as we have no way of injecting scripts into instances after they've
already launched.
There is an ongoing debate about requestFeature().
BONDI spec is
Hi Jonas,
requestFeature() is mainly (still debated, though) for websites, i.e. online
content where the feature is not present.
feature is for packaged widgets only.
However this does not seem to be true
if the exploited code could simply call requestFeature() first, and
then use the feature.
Hi Marcos,
requestFeature() from BONDI 1.0 is an asynchronous API that follows API design
pattern:
http://bondi.omtp.org/1.0/apis/BONDI_Interface_Patterns_v1.0.html#asynchronicity
requestFeature() is described in detail in:
Hi Scott,
In BONDI we have discussed the (has/request)Feature() for some time.
http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf,
section 4.3
A few points for further discussion:
1. feature (at least in BONDI) is an abstract thing, not just one function. So
On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
Hi Scott,
In BONDI we have discussed the (has/request)Feature() for some time.
http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf,
section 4.3
A few points for further
On Tue, Jun 2, 2009 at 7:19 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik
marcin.hanc...@access-company.com wrote:
Hi Scott,
In BONDI we have discussed the (has/request)Feature() for some time.
24 matches
Mail list logo
