Gallery Stats Options

[CSM]

I consider the following a "Random Thought" for many reasons:

• I created this on a whim, just to see if I could.
• I don't wish to bump the nice ToDo Widget so soon.
• This may be a complete waste of mine and your time.
• I don't currently plan on submitting this to the gallery, but if it works out and is well received, I will.

Anyways, to start my random thought.

Okay, so I use Firefox and love it. You can download any number of plugins/add-ons, some of which all do the same thing as another just in a different way.
However, there is one I really do like (besides Mouse Gestures and Tab Mix Plus).
It is called "Update Notifier".

It has several handy features:

• It checks for updates for all plugins/add-ons.
• It can install the updates.
• When Firefox reloads after an update, all your tabs come back!

Now while you don't need to restart Konfabulator! to update a Widget, I thought that it might be nice to provide a central way to check for updates and the like.
It would take me too much time to build a Widget that checks the system (Win and Mac) for opened Widgets and looks for updates.
I would need the Widgets proper name, the inner .kon file name or the Widget's gallery number.

If anyone has seen my update notifier, it looks a lot like the new mail notifier from Thunderbird. In fact I used their blue bordered box with my own images to create mine.
If there was an update, you could click on the box and it would open the gallery page for that Widget.
However, that was only for one Widget. If it had to check multiple Widgets, it would have to accordion-side out all the update boxes.
That's tough to implement.

So I decided after a long time, to take a slightly different approach.
Instead of storing the update code in the Widget, why not outsource it to another Widget?
So now instead of the Widget checking all the Widgets, it checks it for the one that calls it.
But, just getting the version number is easy, why not get all possible information?


So here is my (condensed) idea:

- A Widget calls this Widget with a certain syntax and gets a reply.
- The Widget it is calling has an easily identifiable name.
- The Widget sending the data must also send the "proper name" of the Widget.
Here is the syntax:

CODE

tellWidget("Widget","<data><name>Kitty Clock</name><author>Ricky Romero</author></data>");

//You can also include formating data but it will be ignored.
tellWidget("Widget","<data>\r\n\t<name>Kitty Clock</name>\r\n\t<author>Ricky Romero</author>\r\n</data>");

The receiving Widget will then parse it and send back this data as a string with proper formating*:

• The Widget's gallery number.
• The version number.
• The full date of when last updated.
• Same date as above, broken down:
  • Day
  • Month
  • Year
• Rating [as a number].
• Number of new comments. New being defined as posts since last update. (First page only, for now.)
• URL pointing to the location of the Widget's "chit" image. (Escaped to provide ease of parsing by calling Widget)

More different data (description, history, both Widget screen-shots...) could be added to the response if people want it.

* By proper formatting I mean that the actual return String will include the proper escape characters for the current OS. These are the characters: \r \n \t

The previous would look like the following, if the previously mentioned request for "Kitty Clock" were processed.

CODE

//The following is as it would be displayed by a format following reader/display.
<information>
    <number>36731</number>
    <version>1.0.0</version>
    <update>
        <date>August 4, 2005</date>
        <day>4</day>
        <month>7</month>
        <year>2005/<year>
    </update>
    <rating>4</rating>
    <downloads>58409</downloads>
    <comments>25</comments>
    <chit>http%3A%2F%2Fa191%2Eg%2Eakamai%2Enet%2F7%2F191%2F1560%2F4%2Fgallery%2Ewidgetgallery%2Ecom%2Fminichits%2F36731%2Dminichit%2Epng</chit>
    <timestamp>Wed April 18 2007 19:19:34 GMT-0500 (Central Daylight Time)</timestamp>
</information>

If you have actually read this far, congrats!
I have a download link below to a file containing the following:

• Widget - a Widget that does what I have mentioned above.
• Repeater - a very simple Widget that takes any code given to it by tellWidget() and displays it in a popup.
  (Repeater can be easily modified to test parsing, giving and receiving tellWidget() data.)

Anyways, here is the download link:
Widget and Repeater

[CSM]

3 hours later and no one bites. I guess I need more patience.

I know that Konfabulator! is supposed to check updates soon, but this does more than that.
I thought that at least someone would be interested, especially in the tellWidget()

Well, most of my Widgets suck anyways, so I'm not too surprised.
But on the positive side, I think that Repeater looks good just sitting in the dock, even if it doesn't do anything.

[Drevor]

mmmm ... 6am ... no caffeine yet ...

Im not sure about the idea behind it ... you want other widgets to check for updates though this widget? Why not creating a library that one could include in their widgets instead?

[CSM]

This is so that they don't have to.

Also, if the webpage changes, or I need to update the way the algorithm checks for updates or gets information, all users have to do is download the latest version of this Widget, and it fixes every Widget that uses it.
It saves a lot of hassle.

[FencingFred]

Wow, I think this could be a very promising idea... if Y!W wasn't going to add widget update checking imminently.
I'm not sure I understand what more this widget does. Actually, If I understand correctly, all* it does is send back to the calling widget its current gallery information. Does the calling widget then have to take care of updating itself if it sees fit?

*don't get me wrong, I think it's a very good idea... just that it will probably be obsolete before anyone implements it.

[CSM]

Wow, I think this could be a very promising idea... if Y!W wasn't going to add widget update checking imminently.
I'm not sure I understand what more this widget does. Actually, If I understand correctly, all* it does is send back to the calling widget its current gallery information. Does the calling widget then have to take care of updating itself if it sees fit?

Well, it depends on what people think and how much support it gets. I may just do it anyway.
I was very much thinking about actually adding a feature activated by way of a version number in a <currentVersion></currentVersion>.
This tag would be optional. If present, the Widget would still return data, but would notify the computer's user that such and such Widget is updateable.

I would model the animations and such after my aforementioned updater code.
I would need help though, in getting the Widget to show that multiple Widgets need updates.
I'm thinking that maybe I could have the notifier open a frame* with the list of Widgets needing updates.
This would only happen if multiple Widgets ask at the same time.
Otherwise, it will only slide up the "update window" for that Widget.

However, if the tag is not present, the Widget will only return the data. It will not do any sort of notification.

*I'd need Photoshop help for starters... I am inept at actually making anything that is remotely cool-looking. My two new (non-submitted) comic Widgets are the exception.

*don't get me wrong, I think it's a very good idea... just that it will probably be obsolete before anyone implements it.

Maybe for version checking alone, yes, but this returns much more than that. If you feel that there is more that can be done to prove usefulness, I'd love to hear it. Help is always appreciated.

[g6auc]

3 hours later and no one bites. I guess I need more patience.

In my time zone (BST=GMT+1) your first message was at 1:39am, the second at 4:51am and the third at 6:00am. Quite oddly, I was in bed and asleep when all three were sent!

I'll need to look more closely at what you have done. There could be mileage in having Widgets that offer services to other Widgets, although, as Drevor noted, it would probably be simpler (and much more cpu and memory efficient) to include a library file in the Widget needing the service/function.

I've now run a test. I have both the Repeater and the Widget Widget in my Widgets Folder. I set the Repeater running and send the following to the Widget using applescript:

CODE

tell application "Yahoo! Widget Engine" to send "<information><name>Month Calendar</name><author>Harry Whitfield</author></information>" to widget "Widget"

The Repeater pops up an alert with information about a Widget.

The only problem is that my Widget (Month Calendar) is number 38010. The alert tells me about Widget 41735 (Girlsense Horoscope).

Harry.

This post has been edited by g6auc: Apr 19 2007, 02:55 PM

[CSM]

In my time zone (BST=GMT+1) your first message was at 1:39am, the second at 4:51am and the third at 6:00am. Quite oddly, I was in bed and asleep when all three were sent!

I'll need to look more closely at what you have done. There could be mileage in having Widgets that offer services to other Widgets, although, as Drevor noted, it would probably be simpler (and much more cpu and memory efficient) to include a library in the Widget needing the service/function.

Harry.

Thanks. I should have been asleep, too.

As for the memory, unless it really consumes memory, I'm not worried.
And I am just trying to provide, at the very least, the idea that another Widget can offload the work and code for a service that any Widget author would like to include but doesn't want to have to worry about it.

[g6auc]

As for the memory, unless it really consumes memory, I'm not worried. And I am just trying to provide, at the very least, the idea that another Widget can offload the work and code for a service that any Widget author would like to include but doesn't want to have to worry about it.

I'll go along with that!

To follow on my test above, I've also tried:

CODE

tellWidget("Widget", "<information><name>Month Calendar</name><author>Harry Whitfield</author></information>");

from my Widget Tester Widget with the same (wrong) result.

Harry.

[CSM]

Oops! I forgot to tell Widget no to send it to Repeater. Repeater was just to help with testing for others, and me.
Widget is supposed to send it back to the calling Widget.

As for the wrong result, I as the gallery to search for that Widget name, then take the one tat matches with the author's name.

Update: I just tested you string. You know what? This is very strange!

Try this:

CODE

tellWidget("Widget","<data><name>Month Calendar</name><author>Harry Whitfield</author></data>");

You should now get a correct result.
Why the heck using <information> gives a totally different value is beyond me!

By the time you read this, I will have updated the original post.


Edit: I just tried my Kitty Clock example with the bad tags, and it brings up the horoscope Widget as well. It must be an internal logic error* that defaults to the main page, and the horoscope is the first Widget it selects.

*It must be sending an empty search URL and so, the gallery sends the mainpage.

[g6auc]

Widget is supposed to send it back to the calling Widget.

How does it know which that is?

Why the heck using <information> gives a totally different value is beyond me!

It could be because your parsing function looks for <data>...</data> tags! Incidentally, you could pick out the widget and author names much more easily with a regular expression.

CODE

function ParseTags( string ) {
    this.name = ""; this.author = "";
    string = string.replace(/\r\n?|\n/g, "").replace(/\t/g, "");
    var lookFor = /^<data><name>(.*?)<\/name><author>(.*?)<\/author><\/data>$/;
    var found = string.match(lookFor);
    if (found !== null) { this.name = found[1]; this.author = found[2]; }
}
var sed = "<data>\r\n\t<name>Kitty Clock</name>\r\n\t<author>Ricky Romero</author>\r\n</data>";
var data = new ParseTags(sed);
print('name: ' + data.name); print('author: ' + data.author);

By the time you read this, I will have updated the original post.

You made a mistake (<idata>) in doing that.

More generally, if Widgets are going to send and receive messages, there needs to be a message protocol.
The client needs to send its (i.e. client's) own name, the actual message and a message id ( a nonce, for example, a new UUID used only once would be good).
When the server replies, it needs to send its own (i.e. server's) name, the actual reply, and return the id sent by the client.
This is so that the client can identify one of several requests/replies and for security reasons. A client should ignore replies that do not have a valid id. A Widget could make a request about a third party.

Harry.

This post has been edited by g6auc: Apr 19 2007, 05:23 PM

[CSM]

How does it know which that is?

That is why the requesting Widget has to send the "proper name" with it's submission. That way I can return the data in another tellWidget.
Repeater is totally unnecessary.

Here is a link that has a version of the Widget that sends it back to the Widget it came from. I only changed one line.

It could be because your parsing function looks for <data>...</data> tags! Incidentally, you could pick out the widget and author names much more easily with a regular expression.

CODE

function ParseTags( string ) {
    this.name = ""; this.author = "";
    string = string.replace(/\r\n?|\n/g, "").replace(/\t/g, "");
    var lookFor = /^<data><name>(.*?)<\/name><author>(.*?)<\/author><\/data>$/;
    var found = string.match(lookFor);
    if (found !== null) { this.name = found[1]; this.author = found[2]; }
}
var sed = "<data>\r\n\t<name>Kitty Clock</name>\r\n\t<author>Ricky Romero</author>\r\n</data>";
var data = new ParseTags(sed);
print('name: ' + data.name); print('author: ' + data.author);

You also made a mistake <idata> in doing that.

Fixed. Hey thanks for the regex. I just wanted to make sure that all the tags were closed.

More generally, if Widgets are going to send and receive messages, there needs to be a message protocol.
The client needs to send its (i.e. client's) own name, the actual message and a message id.
When the server replies, it needs to send its own (i.e. server's) name, the actual reply, and return the id sent by the client.
This is so that the client can identify one of several requests/replies. A Widget could make a request about a third party.

Harry.

I suppose. I just thought that the tags were enough. I wanted to keep this simple.

[CSM]

This is so that the client can identify one of several requests/replies and for security reasons. A client should ignore replies that do not have a valid id.

Oh, okay. There would still be 2 messages send out and receive but both would include an appropriate id tag.

I will start working on a format for the id. The tags will be as follows.

<clientID></clientID>
<serverID></serverID> *

*for lack of a better name.

For my simplicity, I may have the server generate a random UUID. As for the client, well, they could submit one too, but I would have to check length, number of dashes (sections), as it would be hard to do anything else.
It wouldn't matter if the client Widgets UUID is hard-coded either.


So to recap, the next version will include:

• Returning an <error> tag with a message when there is a problem. No more popups.
• Optional <version> tag when sending a request. This will cause my Widget to deal with the version checking.
• <clientID> and <serverID> tags.
• Returning replies to the Widget. not Repeater.
• Regex to get tags. (which may help me enforce proper tags better....)

[g6auc]

I just thought that the tags were enough. I wanted to keep this simple.

How about something like this:

CODE

<message>
    <version>1.0</version>
    <sender>Sender Widget</sender>
    <uuid>18791960-ee9c-11db-aa8c-0016cb01fc35</uuid>
    <data><name>Month Calendar</name><author>Harry Whitfield</author></data>
</message>

This can be handled easily with regExp, or with the XML parser.

Harry.

[CSM]

I don't want to sound like I'm just agreeing, but I like it!
With regex this is easy! (I hope. I'm regex inept, but I'll play with your code to achieve a solution.)

Do I use the same format for the message sent back? (Except replace <data> with <information>)

[barnettedward]

I have no idea what any of you are talking about..

I like pancakes!!

[g6auc]

...I may have the server generate a random UUID. As for the client, well, they could submit one too, but I would have to check length, number of dashes (sections), as it would be hard to do anything else. It wouldn't matter if the client Widgets UUID is hard-coded either.

I think you may have missed my point.

There is no point in the server generating a UUID, unless there is to be a further dependent exchange.
There is no point in the server checking the client's UUID - all it has to do is return it with any reply.
The client's UUID could be hard coded, but it cannot then make several requests concurrently.

[CSM]

I have created a Widget that takes input form "tellWidget()" and returns by the same method, all the gallery information about an asking Widget.
(except both icons, the description and history. I deemed them not really necessary, unless a lot of people need/want it.)

Harry has suggested that I use regex*, to better enforce ad parse tag structure for the messages.
He has also suggested that I add a security component to make sure that it is harder to just send or spoof a message by accident or on purpose.


*Regular expressions. They are used to parse strings for a matching message to the one you are searching for.


BTW, pancakes are good.

[g6auc]

With regex this is easy! (I hope. I'm regex inept, but I'll play with your code to achieve a solution.)

It may be better to ignore Unicode white space between certain tags - you can't get rid of spaces everywhere.

Do I use the same format for the message sent back? (Except replace <data> with <information>)

Why not? I'd not even replace <data> with <information>. You could add a type tag with something like <type>request</type> or <type>response</type>.

This post has been edited by g6auc: Apr 19 2007, 06:06 PM

[CSM]

I think you may have missed my point.

There is no point in the server generating a UUID, unless there is to be a further dependent exchange.
There is no point in the server checking the client's UUID - all it has to do is return it with any reply.
The client's UUID could be hard coded, but it cannot then make several requests concurrently.

Okay, the server one I get.

Well, if I'm not checking the UUID, then how would I know if it is the same a request currently being processed?
I would have to keep a list of currently being processed job's UUIDs (which will be removed from the list when finished).

Or is your topic on the Earth and I'm orbiting Saturn? It's entirely possible.


Edit: I like it!
In response to above though, I would lump the optional <version> tag with the data section. A simple if statement can be used to parse those with it versus those without.

CODE

<data>
    <type>request</type>
    ...
</data>
<data>
    <type>response</type>
    ...
</data>