learners and co-ordinating access to
functionality. For more background on the projects themselves, see:
http://www.tencompetence.org
http://palette.ercim.org/
Cheers,
Scott
/-/-/-/-/-/
Scott Wilson
Assistant Director, JISC CETIS
University of Bolton
scott.bradley.wil...@gmail.com
http
On 17 Jan 2009, at 05:26, Marcos Caceres wrote:
In addition, both projects wanted to add additional functionality to
the API; this has included state coupling and shared states to enable
richer interaction between (a) widgets in the same user context and
(b) instances of the same widget from
Hi Marcos,
A widget engine, in our use of the term, is a server-side web
application that publishes widgets and implements the Widget API as a
web service accessible via AJAX. As it stands all browsers will block
any cross-domain Javascript requests, and this will apply in all cases
Scott,
On Wed, Jan 28, 2009 at 9:51 AM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
Ok, I see where you are coming from now. Our definition of widget is
different. Please see the Differences from Web Widgets section in the
Widgets Landscape document [1]. Our intention is to allow
This is a pretty radical change; I can certainly see the logic of it
in terms of reducing spec overlap. However, it does presume that
semantically a widget preference is the same as client-side storage.
In our implementation, storage is definitely server-side, so this
mechanism would not
.)
S
On 11 Feb 2009, at 02:54, Jonas Sicking wrote:
On Wed, Feb 4, 2009 at 1:26 AM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
This is a pretty radical change; I can certainly see the logic of
it in
terms of reducing spec overlap. However, it does presume that
semantically
Hi Marcos,
PALETTE adopted this mechanism in their extension profile of the spec,
and it seems like a very useful addition. Its also used in some web
widget galleries to dynamically expose preferences to users as setup
forms prior to installing a widget.
The only caveat would be if such
I agree that postponing any detailed work may be the most pragmatic
answer, however oAuth is actually a very important technology for
Widgets.
oAuth enables a user of an application such as a widget to link that
application to an external service, without the application storing,
or
Hi everyone,
Here are the images I showed at the F2F in Paris:
http://www.slideshare.net/scottw/widgets-and-wookies
Cheers,
Scott
/-/-/-/-/-/
Scott Wilson
Assistant Director, JISC CETIS
University of Bolton
scott.bradley.wil...@gmail.com
http://www.cetis.ac.uk/members/scott
smime.p7s
Hi everyone,
Here's a sample of our widget gallery output from Wookie - again not
as a proposition but just to share an example of the sort of content
that tends to be included in these cases.
(Note in our system the client requests an instance of a widget using
the widget identifier,
We've managed to implement Storage for Widget.preferences as an
overlay over the older get/set method without any problems.
One issue though is the HTML5 doc uses some syntax that relies on a
Rubyesque method_missing capability that just isn't present in many
environments, including,
greater.
The only debate is whether to standardize the existing practice (Apple/
Nokia/Opera method signatures) or attempt to harmonise with future
practice (use Web Storage method signatures).
S
On 6 Apr 2009, at 14:45, Anne van Kesteren wrote:
On Mon, 06 Apr 2009 15:28:47 +0200, Scott
In our system when a widget is instantiated we generate our own
instance hashes which we append to the widget URL as a parameter, and
our Storage implementation uses this parameter when it needs to make a
request back to our prefs web service to load preferences, or to set a
preference.
indeed be solved easily within the currently proposed framework.
I'm not sure whether the current requirements document actually
answers this question.
--
Thomas Roessler, W3C t...@w3.org
On 24 Apr 2009, at 18:02, Scott Wilson wrote:
In our system when a widget is instantiated we generate
Is there a particular preferred format for submitting use cases?
S
On 21 May 2009, at 14:55, Arthur Barstow wrote:
This is a Call for Inputs regarding Use Cases and Requirements for
the Widgets Access Requests spec:
http://dev.w3.org/2006/waf/widgets-access/
Please submit inputs before
RXX: Restricted access to remote web services using white/black lists
Motivation: Security, Current development practice or industry best-
practice, Interoperability
Rationale:
A Widget may need to make use of external web services in order to
function, for example using AJAX to obtain
I won't be able to make the call tomorrow, so if there any questions
about the UC I submitted under item 3a, please make them on the list
today and I'll reply ASAP.
S
On 27 May 2009, at 14:05, Arthur Barstow wrote:
Below is the draft agenda for the May 28 Widgets Voice Conference
(VC).
://tencompetence.cvs.sourceforge.net/viewvc/*checkout*/tencompetence/wp6/org.tencompetence.widgetservice/widgets/test.wgt
S
/-/-/-/-/-/
Scott Wilson
Assistant Director, JISC CETIS
University of Bolton
Projects:
FeedForward: http://getfeedforward.org
Wookie: http://getwookie.org
On 3 Jun 2009, at 16:38, Marcos Caceres wrote:
Maybe, but that is just more work. That is the reason I am editor of
all the specs, so I can keep consistency across all of them. So,
unless I die in a unforeseen accident, I think we should be ok.
And a very good job you're doing too - so please
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
-
From: Scott Wilson [mailto:scott.bradley.wil...@gmail.com]
Sent: Thursday, June 04, 2009 10:58 AM
To: Jonas Sicking
Cc: Marcin Hanclik; Henri Sivonen; public-webapps
Subject: Re: [widgets] What does it mean to have an unavailable API
Security is on UC; another is resource use. If the UA only
is
an implementation strategy worth supporting (hence making the API
conform to Storage).
S
On 8 Jun 2009, at 19:34, Marcos Caceres wrote:
2009/4/25 Scott Wilson scott.bradley.wil...@gmail.com:
I think perhaps the underlying assumptions may vary according to
the type of UA?
However, I think even
W3C
Social Web group, and so perhaps needs a cross-group discussion as to
what we think would be a good approach?
S
On 8 Jun 2009, at 19:34, Marcos Caceres wrote:
2009/5/31 Scott Wilson scott.bradley.wil...@gmail.com:
Hi everyone,
Something that may be of interest if you've been following
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.
In practice, we've been serialising data into JSON and storing it in a
preference as text content whenever we've needed a preference value to
contain structured information.
Having the content of the preference value as text content at least
makes it easier to know how to start
://osswatch.jiscinvolve.org/2009/07/17/wookie-accepted-into-apache-incubator/
Cheers,
S
/-/-/-/-/-/
Scott Wilson
Assistant Director, JISC CETIS
University of Bolton
Projects:
FeedForward: http://getfeedforward.org
Wookie: http://getwookie.org
scott.bradley.wil...@gmail.com
http://www.cetis.ac.uk/members/scott
-1
No, we should keep widget.preferences.
If a UA wants to, it can simply implement it using:
widget.preferences = window.localStorage;
If it doesn't, the UA can do its own implementation, which we do for
example, as for our UA localStorage is not an appropriate
implementation, as our
On 20 Jul 2009, at 16:29, Marcos Caceres wrote:
On 7/20/09 4:32 PM, Scott Wilson wrote:
-1
No, we should keep widget.preferences.
If a UA wants to, it can simply implement it using:
widget.preferences = window.localStorage;
If the UA wants to seems kinda bad... I think the spec should say
Agreed.
Currently I would summarize the situation as:
A UA that conforms to the W3C A+E spec MUST make widget.preferences
available.
The UA environment MAY also provide access to window.localStorage
The UA MAY use window.localStorage to store widget.preferences (and
therefore the two
+1
Sounds sensible - I've had a hard time figuring out what to do about
these without the view modes spec being completed.
S
On 21 Jul 2009, at 17:32, Marcos Caceres wrote:
I think we should remove onmodechange and viewMode from the AE spec
and move them to the View modes spec (View
/2006/waf/widgets-wm/Overview.src.html
/-/-/-/-/-/
Scott Wilson
Assistant Director, JISC CETIS
University of Bolton
Projects:
Apache Wookie: http://incubator.apache.org/projects/wookie.html
FeedForward: http://getfeedforward.org
scott.bradley.wil...@gmail.com
http://www.cetis.ac.uk/members/scott
Hmm, well as you really can only test observable behaviour - and the
behaviour of a widget is really what the AE spec is concerned with...
I can see the problem we have here.
If we completed the widget catalogue Atom feed profile we mooted a
while back that would also give us another
On 10 Aug 2009, at 10:00, Marcos Caceres wrote:
Secondly, although some elements are not exposed as part of AE (e.g.,
icon and license), there are still conformance requirements as to how
the user agent is supposed to expose the content of those elements to
the end-user. For example, for the
First off, a nice easily-remedied typo:
2. Definitions
Author script
An script running within the widget context (e.g., some ECMAScript).
Should be A not An
Second, a more thorny issue:
5. Storage Areas
A storage area is a data-store that is unique for the origin of a
widget, which a user
The Storage [1 interface ] is defined as:
interface Storage {
readonly attribute unsigned long length;
getter any key(in unsigned long index);
getter any getItem(in DOMString key);
setter creator void setItem(in DOMString key, in any data);
deleter void removeItem(in DOMString key);
Section 6.4:
Several occurrences of preference rather than preferences
attrribute:
A user agent must initialize the preference attribute in accordance
with this specification.
Upon getting the preference attribute, the user agent must return a
Storage object that represents the storage
The question is important as it affects conformance. Currently we only
support the first of the three methods you've stated, and there was
discussion on the list previously as to whether the second of the
three was even possible in a pure JavaScript implementation (search
for syntactic
Metadata Attributes and the Storage Area
I don't think its clear from the spec if metadata attributes are
within the scope of widget.preferences and must be stored in the same
storage area.
E.g. Does widget.preferences.getItem(name) == widget.name? if not,
On 4 Sep 2009, at 15:46, Marcos Caceres wrote:
On Fri, Aug 21, 2009 at 1:10 PM, Scott
Wilsonscott.bradley.wil...@gmail.com wrote:
Metadata Attributes and the Storage Area
I don't think its clear from the spec if metadata attributes are
within the
scope of
Hi everyone,
There is going to be a meetup at ApacheCon US in November on the area
of widgets and related technologies:
http://wiki.apache.org/apachecon/SocialAndWidgetsMeetup
This is an informal event for people interested the Shindig
(OpenSocial), Wookie (W3C Widgets), and SocialSite
I've investigated this issue, and I'm afraid it does not seem possible
to have protected attributes in a pure JavaScript implementation.
While private attributes and protected methods are supported using
closures, protected attributes are not; a private attribute exposed
using a public or
I haven't seen any comments yet on this issue?
(This may just be me misunderstanding the intended meaning of origin
in this context.)
On 19 Aug 2009, at 11:42, Scott Wilson wrote:
sue:
5. Storage Areas
A storage area is a data-store that is unique for the origin of a
widget, which a user
Hmm, I raised this one too.
I can't see how the origin handles instances exactly, and the concept
of origin doesn't seem all that relevant to our implementation
anyway - it looks more like something for browser makers to worry over?
Why is origin of a widget preferable to instance of
I agree that pattern implies that you could use regular expressions
(or similar) - this would be a much more flexible way to handle
access, but does have implications (e.g. no need for a 'subdomains'
attribute).
In our system we will be using the access element to prompt the server
admin
Apache Wookie got 2 that failed, and the rest couldn't run - I think
because WindowWidget is not required for all UAs to conform, but is
required as a prerequisite by the test.
After some tweaking I got some slightly more useful results... so its
definitely a start!
We've been using this
I've added the tests to Apache Wookie as JUnit tests that directly
load the test .wgt's from the SVN - so far so good!
However testing has revealed a few possible bugs in the test cases:
Assertion 14: Test AY
Test the UA's ability process the height attribute. To pass, the
On 18 Nov 2009, at 12:02, Marcos Caceres wrote:
2009/11/14 Scott Wilson scott.bradley.wil...@gmail.com:
woops, fixed.
Assertion 34: Test d7, d8
===
These test cases both contain badly-formed XML:
widget
content
/widget
Presumably these ought to be:
widget
content
In PC the author element is defined as: An author element represents
people or an organization attributed with the creation of the widget.
with zero or one occurrence [1]
I was wondering how the element is used to represent more than one
person? The example used shows two names, but there
Thanks Marcos,
I'm happy with this solution.
S
On 19 Nov 2009, at 21:05, Marcos Caceres wrote:
On Thu, Nov 19, 2009 at 8:53 PM, Marcos Caceres marc...@opera.com
wrote:
Hi Scott,
Artb would like to include this comment as part of our Disposition of
Comments for PC. We intend to republish
Another test case issue:
Assertion 30: test ag, ah
===
I think these two got mixed up; ag should result in P A S S and ah
should result in PASS.
S
On 19 Nov 2009, at 23:05, Marcos Caceres wrote:
On Wed, Nov 18, 2009 at 1:59 PM, Scott Wilson
scott.bradley.wil...@gmail.com
Hi,
On 28 Nov 2009, at 22:36, Marcos Caceres wrote:
I am hopeful that other implementers will work with the WG to achieve
interoperability across the widget specs by providing us with test
suite results and means of verifying those results (and helping us
improve the test suite). I'll be
Some more potential test case errors and fixes:
==
bl.wgt
✔ Tests the UA's ability to locate an icon in a locale folder and at
the root of the widget. To pass, after processing, the icons list must
contain a pointer to locales/en/icon.jpg, and icon.png, which is
at the root of the
Hi Marcos,
The latest PC test results for Apache Wookie (incubating) are:
165 tests
16 ignored
17 failures
132 passes
Failed: dc,d4,an,co,za,bv,rd,b2, ao,cp,cj,af,e8,bl,bm,bn,zz (though
the last four test cases may be in error; see previous email)
Ignored (not automatically tested - doesn't
On 3 Dec 2009, at 17:26, Marcos Caceres wrote:
On Sun, Nov 29, 2009 at 6:03 PM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
Some more potential test case errors and fixes:
==
bl.wgt
✔ Tests the UA's ability to locate an icon in a locale folder and
at the
root of the widget
On 9 Dec 2009, at 13:46, Robin Berjon wrote:
On Dec 9, 2009, at 14:31 , Cyril Concolato wrote:
Actually, I have a problem with the way the test suite result are
expressed. Since there is no normative algorithm for the selection
of the actual displayed icon, why should the test suite results
On 9 Dec 2009, at 23:34, Marcos Caceres wrote:
On Wed, Dec 9, 2009 at 2:46 PM, Robin Berjon ro...@berjon.com wrote:
On Dec 9, 2009, at 14:31 , Cyril Concolato wrote:
Actually, I have a problem with the way the test suite result are
expressed. Since there is no normative algorithm for the
Test cases e5, e6, z1 and z2 test the ability of a UA to use a widget-
specified charset (ISO 8859-1); however the PC specification states
that a UA only has to implement UTF-8, and support for additional
encodings is optional.
Do these test cases then really only require that a UA
I've finally narrowed it down to just one test case to pass PC
conformance!
Unfortunately it involves implementing SNIFF...
Does anyone know of an implementation already existing in Java?
S
/-/-/-/-/-/
Scott Wilson
Apache Wookie: http://incubator.apache.org/projects/wookie.html
On 6 Jan 2010, at 08:56, Cyril Concolato wrote:
[snip] 1 fails because we don't implement SNIFF. I don't know if we
will. [snip]
Actually you don't need to implement SNIFF to pass that particular
test, as it only requires you do the extension-processing part of the
algorithm.
See,
On 6 Jan 2010, at 10:08, Cyril Concolato wrote:
I think you misunderstood me.
There is a difference between an 'unsupported'/'unavailable' feature
as 'foo:bar' in your example and an 'invalid feature name' as in the
test-suite example:
widget
named4/name
feature name=invalid feature IRI
On 6 Jan 2010, at 12:09, Cyril Concolato wrote:
Le 06/01/2010 11:22, Scott Wilson a écrit :
On 6 Jan 2010, at 08:56, Cyril Concolato wrote:
[snip] 1 fails because we don't implement SNIFF. I don't know if we
will. [snip]
Actually you don't need to implement SNIFF to pass that particular
Hi Marcos,
I think this is a really good piece of work - I'll be pointing a few
people from other spec orgs at the draft as its addressing a common
requirement.
(As an implementer I found the approach - especially the
implementation reports - really useful and easy to follow in
Hi Marcos Dominique (and other widsters),
I've been implementing our semi-automated testing of Apache Wookie[1]
for TWI[2], and have spotted a few errors in the test cases[3] you may
want to fix:
za: URL of widget is incorrect; it should be
Hi everyone,
Just a quick heads up that I've checked in some fixes to bugs in the
Widget Interface test cases in CVS.
I also noticed an issue with the WebIDL test case that I wasn't
willing to dive into as I believe it is auto-generated from the
documentation (?) - this is a
On 9 Feb 2010, at 09:22, Marcos Caceres wrote:
On Tue, Feb 9, 2010 at 9:54 AM, Cyril Concolato cyril.concol...@enst.fr
wrote:
Le 08/02/2010 13:29, Robin Berjon a écrit :
On Feb 5, 2010, at 16:18 , Marcos Caceres wrote:
On Thu, Feb 4, 2010 at 6:41 PM, Cyril
On 9 Feb 2010, at 12:49, Robin Berjon wrote:
Hi Cyril,
On Feb 9, 2010, at 09:52 , Cyril Concolato wrote:
Le 08/02/2010 13:26, Robin Berjon a écrit :
I'm not sure what you mean? The preference storage should remain
available across instantiations of the widget. This could probably
be
/2010/webapps/charter/Overview.html
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
/-/-/-/-/-/
Scott Wilson
Apache Wookie: http://incubator.apache.org/projects/wookie.html
scott.bradley.wil...@gmail.com
http://www.cetis.ac.uk/members/scott
smime.p7s
Description: S/MIME
On 11 Feb 2010, at 01:10, Jonas Sicking wrote:
I don't disagree with you on the implementation side (and Im happy
to hear
that you think it can be implemented - I'll keep my fingers
crossed). On the
author side, I honestly don't know how much of a difference it will
make.
I'm sure someone
On 11 Feb 2010, at 13:08, Arthur Barstow wrote:
On Feb 11, 2010, at 5:32 AM, ext Robin Berjon wrote:
On Feb 11, 2010, at 05:40 , Doug Schepers wrote:
Scott Wilson wrote (on 2/9/10 10:32 AM):
There are a couple of additional areas it would be useful to
consider
for future work
.org/2009/dap/contacts/
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Scott Wilson wrote (on 2/12/10 5:39 PM):
Specifically I'm thinking of access to friends/friends-of lists from
author scripts in a Widget runtime. This is something of interest to
widget developers
for doing this in Webapps and work instead with the Social Web group
as you suggest.
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Scott Wilson wrote (on 2/13/10 5:21 AM):
Hi Doug,
I'm not adamant that these requirements are met specifically just for
Widgets, just
On 17 Feb 2010, at 00:19, Harry Halpin wrote:
On 17 Feb 2010, at 00:19, Harry Halpin wrote:
Yes, we over in the Social Web XG would be happy to provide some space
where efforts like this one can be done, in particular a Social API
requirements telecon and e-mail discussion with WebApps would
Hi both,
Apache Wookie (incubating) currently implements the widget.openURL
method by directly calling the browser's window.open() function - in
this example is there anything particularly special about the fact its
being called by a widget? Should our implementation do anything extra,
On 18 Feb 2010, at 21:52, Arve Bersvendsen wrote:
On Thu, 18 Feb 2010 22:09:00 +0100, Scott Wilson scott.bradley.wil...@gmail.com
wrote:
Hi both,
Apache Wookie (incubating) currently implements the widget.openURL
method by directly calling the browser's window.open() function
On 22 Feb 2010, at 18:11, Marcos Caceres wrote:
Dear i18n core,
I'm writing on behalf of the Web Apps WG about the possibility of
conducting a joint teleconference to discuss some issues with the
ITS [1] features in the Widgets 1.0 Family of Specifications.
Basically, we would like to
Hi Marcos,
On 26 Feb 2010, at 17:44, Marcos Caceres wrote:
Hi i18n WG,
I've added the dir attribute and span elements to the Widgets PC
Specification, as well as a bunch of examples (which are wrong, so I
would really appreciate some help with these!).
The dir attribute is specified here:
-- Lab126
Internationalization is not a feature.
It is an architecture.
-Original Message-
From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core-
requ...@w3.org] On Behalf Of Scott Wilson
Sent: Monday, March 01, 2010 9:44 AM
To: marc...@opera.com
Cc: public-webapps; public-i18n-c...@w3
On 2 Mar 2010, at 11:28, Marcos Caceres wrote:
On 1/03/10 11:47 PM, Phillips, Addison wrote:
Thanks Addison - and yes, I think this makes a lot of sense for a
content-style spec like HTML, however as the Widgets PC is a
configuration document most of which is IRIs, integers and so on
rather
I've just been reading through the WARP spec again, and in particular this
stood out:
In the default policy, a user agent must deny access to network resources
external to the widget by default, whether this access is requested through
APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe,
On 5 May 2010, at 10:40, Robin Berjon wrote:
On May 4, 2010, at 19:29 , Scott Wilson wrote:
I've just been reading through the WARP spec again, and in particular this
stood out:
In the default policy, a user agent must deny access to network resources
external to the widget by default
On 11 May 2010, at 15:58, Marcos Caceres wrote:
On Tue, May 11, 2010 at 3:55 PM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
Hi Marcos,
I'll make a start on tests for the assertions about correctly processing the
element (6-13).
I've checked in tests for ta-6 through ta-9.
I'm
Hi Christoph,
On 17 Jun 2010, at 14:26, Christoph Storm wrote:
Hi,
I am currently very busy reading your papers about W3C Widgets because I am
writing my master thesis about Widgets. The title is Device interoperable
data visualization using standard W3C Widgets - the important word is
On 30 Jun 2010, at 14:30, Marcos Caceres wrote:
I've evaluated the discussions in this thread and am strongly leaning
towards proposing we drop openURL() from the specification on privacy
and security grounds.
Although I can think of cases where it might be useful to have a
widget
On 16 Aug 2010, at 21:29, Bernard Traversat wrote:
On 8/16/10 2:34 AM, Rich Tibbett wrote:
On 14/08/2010 03:12, Bernard Traversat wrote:
Should we have a more explicit way to specify and notify users that some
updates may require data conversion and
user data will be converted after the
Test DR appears to be incorrect:
Test the UA's ability to handle a feature element without a name attribute. To
pass, the feature list must contain one feature named 'feature:a9bb79c1' whose
required value is false.
The test widget contains the following config.xml:
widget
I'm also getting a Zip file error on the i18n-039 040 sets (these are the
only ones I've implemented so far):
java.util.zip.ZipException: oversubscribed dynamic bit lengths tree
They seemed to work OK earlier on yesterday, but seem to have become recently
corrupted. (They won't unzip using
- even manually copying it into a HTML file with the div attribute in every
combination and opening in every browser I've got (including Opera ;-) has the
same result!
On 5 Sep 2010, at 23:24, Marcos Caceres wrote:
On 9/4/10 4:54 PM, Scott Wilson wrote:
I'm also getting a Zip file error
:25 PM, Scott Wilson wrote:
To be honest I've been having problems with the i18n test cases
generally. For example:
Tests that LRO direction applies to the name element. To pass, the
displayed value must render as םפללחק.
I can't get the text in that config.xml to show as anything other
On 17 Sep 2010, at 01:30, Marcos Caceres wrote:
Hi Nathan,
There are many applications that are currently stuck using a server
because there is no clear path to deploying 100% client side
applications, examples include micro-blogging clients, note/task-pads,
image editors, contact
I've been having a go at implementing the various i18n test cases in Apache
Wookie. I'm planning on processing them in two ways:
1. For the parser, checking the correct values are being persisted for text
direction, both for the element's dir attributes where allowed, and also that
span
On 30 Sep 2010, at 16:51, Phillips, Addison wrote:
Hi Art,
No, I don't think it does. While the means by which the (user/system default)
locale is determined may be implementation dependent, it is still necessary
that the runtime determine what it is. The Widget interface thus needs to
Actually, just to totally contradict myself, we implemented the locale
attribute of the Widget interface and forget to take it out again when it was
removed from the spec :-)
On 30 Sep 2010, at 20:37, Scott Wilson wrote:
On 30 Sep 2010, at 16:51, Phillips, Addison wrote:
Hi Art,
No, I
I've just had a look at this:
https://apps.mozillalabs.com/
In some respects this is very much what we are aiming for (apps using
HTML+JS+CSS) however it proposes a new proprietary app manifest format for
Widgets that is almost identical to PC, plus an auto-update spec (that isn't
Widget
On 20 Oct 2010, at 19:40, Mike Hanson wrote:
Hi there -
I can speak for the technical aspects of the Apps project and relay feedback
as needed.
We had looked at the Widget Packaging spec earlier in the project and had
steered away from it because we were focused on the in-browser/live
Hi Bryan,
We've looked at this in Apache Wookie, which does use Widgets in a
browser/webserver context. The general approach we've been discussing is
similar to how Apache Shindig handles oAuth - to put the oAuth logic within the
framework itself rather than in the Widget. So these issues
On 26 Nov 2010, at 07:34, Peter Dekkers wrote:
I've been developing a platform for running multiple types of widgets in
regular web pages and of course support for the W3C widgets should not be
missing. A very nice specification. I especially like the fact that the
deployment unit contains
(NB changed subject prefix to [Embedding] as per Art's suggestion)
On 26 Nov 2010, at 18:37, Peter Dekkers wrote:
First of all, thanks to everyone replying and providing useful background to
this first time poster. I did go through the provided links of the past
threads and the different
# dl (download, files) Expected: invalid
Test the ability of the UA to verify a zip archive. To pass, the user agent
must treat this as an invalid widget (archive is encrypted - password is test).
The download is just a regular zip archive and isn't encrypted.
smime.p7s
Description: S/MIME
Tests bd,be,bf for assertion ta-DwhJBIJRQN seem to have gone - have these been
removed from the test suite or been renamed?
smime.p7s
Description: S/MIME cryptographic signature
# bm (download, files)
Tests the UA's ability to deal with custom icon declaration in the config
document and matching default icons. To pass, the icons list must contain a
pointer to locales/en/icon.jpg, and icon.png, which is at the root of the
widget. The icons list can be in any order, so
1 - 100 of 155 matches
Mail list logo
