Hello.
Better late then never: I sent this email 2 months ago :D
But I see the flux of emails everyday on this mailing list, and I
totally understand!
Anyway, funny enough, just this morning I was saying to some colleagues
that there is no current support in the config.xml for declaring
I received an email from Arve explaining the possible spoofing
scenario.
He says this, and I think he is right:
Arve
Forgive my ignorance, but... spoofing attack? O_o
1. Widget A is started in Floating mode
2. Widget A requests, and gets a mode change to Application mode
3. Widget A creates UI
I agree.
- No exception to maintain coherence.
- Name changeMode(mode name).
Arve It should be noted, however, that this is problematic on device for a
number of reasons,
given that floating or mini widgets would typically exist on some desktop
or in an application
grid, so these mode
Hello.
Does anyone agrees that probably we missed an API?
Something like widget.changeMode(String newMode);?
This should allow the widget to ask the WUA to change it's mode: of course
the WUA can refuse to do so, but I think the API should be available.
Any idea/feedback about this?
Regards
I agree with Scott's concern.
I'm not 100% up-to-speed with the latest modification to the HTML5 specs
(if any) but I remember that this kind of Rubyesque way of accessing
elements in the Storage is only present into the attached usage
examples, but there is none in the API described in the
Mmmm.
And how we define more than one viewmode?
I mean, apart from the default one for the content, was not decided to give
to the developer the possibility of declaring what modes the widget supports
and how (in terms of size)?
Am I missing something?
Thanks
---
Ivan De Marino
Orange Labs
Arve, I'm glad you find a way to push this in! ;)
Regards
---
Ivan De Marino
Orange Labs
Mobile and Web Software Engineer, RD UK
tel. +44 20 8849 5806
mob. +44 7515 955 861
mob. +44 7974 156 216
ivan.demar...@orange-ftgroup.com
This e-mail, and any files transmitted with it, is intended only
Hello.
Just to clearify: I never spoke about implementations.
I always spoke about interfaces to define in this Standard: adoption and
implementation is a personal step.
Neither the usage of a server side component nor a direct client side
javascript extension was in my target.
If this matter was
Hello.
I'm trying to stress a bit the current implementation of preferences
storage, comparing it to the LocalStorage.
I see that a preferences array was introduced, but this araise another
problem.
A Javascript Array it's NOT a map of key/value pairs. This means
that the preferences will have
Hi Scott,
I see what you mean. My mistake: I completelly missed that part of the
email.
As for your implementation, of course this could be a solution that will
accommodate things.
Still, there is an important set of functionalities that the HTML5 specs
offer that is missed by the
Hello.
I'm following the specs evolving for Window Modes
(http://dev.w3.org/2006/waf/widgets/#window-modes).
Given the fact that the content tag has an occurrence of 0 or 1, and the
fact that the mode is one, my question is:
- Would it be possible to have widgets that have multiple views?
I
Hi.
I understand what you mean now.
My point of view was basically related to the APIs exposed by the Local
Storage and Session Storage interface.
=5.11.1.2 The Storage interface=
interface Storage {
readonly attribute unsigned long length;
[IndexGetter] DOMString key(in unsigned long
12 matches
Mail list logo
