From: Edward B. <ed...@de...> - 2008-12-01 09:47:14
|
Sven, Thank you for this detailed communication. We are eager to make wider use of Snarl. We will give you some good feedback shortly, but I wanted to copy Dave Woodward right away. Ed On Dec 1, 2008, at 4:13 AM, Sven Walther wrote: > Hi @all, > > As Snarl 2.1 is on the horizon and it will be officially feature web > integration using JSON for the first time I started thinking this > weekend on how we can make a much more complete interface in one of > the > following versions. > > There are two main things that I think are missing compared to the > real > application interface. The first (and easier one) is that displaying > custom images next to the notification is one of the things all the > users (including me) love. So allowing http://, https:// and maybe > ftp:// URLs to images would be a great thing. I made it for Witty (the > Twitter client where I just embedded Snarl support a few days ago) > already and it could be as easy as downloading the image to a > temporary > location and then use it for display (maybe with a timeout to avoid > net > problems producing hanging alerts). > > The other thing is the interaction. And this is what I thought about > quite some time this weekend and I think I have had some good general > ideas for that. First of all I would propose an all in one > registration > command (something quite similar as the new one in V39) to initialize > the app registration. This could be a JSON notification with two > parameters - first a unique ID (will come to that later) and second an > URL where to find the configuration. As I am someone always thinking > in > XML I would propose that under this URL there could be a file filled > with something like this: > > <?xml version="1.0" encoding="utf-8"?> > <snarlWebApp> > <header> > <appTile>My web app</appTitle> > <appName>myWebApp</appTitle> > <appIcon>http://xxx</appIcon> > <appReturnID open="false">http://...%UNIQUEID%_%ALERTID%</ > appReturnID> > </header> > <alertClasses> > <alertClass> > <alertName>myFirstAlert</alertName> > <alertTitle>My First Alert</alertTitle> > <alertDisplayTime>15</alertDisplayTime> > <alertLeftMouse > open="true">http://xxx/yyy_%UNIQUEID%_%ALERTID%</alertLeftMouse> > <alertMiddleMouse > open="false">http://xxx/yyy_%UNIQUEID%_%ALERTID%</alertMiddleMouse> > <alertRightMouse > open="true">http://xxx/yyy_%UNIQUEID%_%ALERTID%</alertRightMouse> > <alertTimeOut > open="false">http://xxx/yyy_%UNIQUEID%_%ALERTID%</alertTimedOut> > <alertClosed > open="false">http://xxx/yyy_%UNIQUEID%_%ALERTID%</alertClosed> > </alertClass> > <alertClass> > <alertName>mySecondAlert</alertName> > <alertTitle>My Second Alert</alertTitle> > <alertDisplayTime>15</alertDisplayTime> > ... > </alertClass> > <alertClass> > <alertName>myThirdAlert</alertName> > <alertTitle>My Third Alert</alertTitle> > <alertDisplayTime>15</alertDisplayTime> > ... > </alertClass> > </alertClasses> > </snarlWebApp> > > Let's talk about the placeholders %UNIQUEID% and %ALERTID%. ALERTID > would be (as it is in the normal interface) the ID of the alert. But > in > the case of a web app the web developer should choose the ID rather > than > Snarl so he knows when he get's his response to which sending > command it > belongs (that's the one greatest difference between desktop apps web > apps - the is no bidirectional communication) > > But there is a great difference between a desktop app and a web app - > one web app can have multiple (not to say many...) different Snarls on > different client machines to deal with. So the web developer needs to > know if alert 123 is clicked on which client this happend - and this > is > where %UNIQUEID% will apply. > > This UNIQUE ID is generated by the web developer (and send as > pareamter > in the intialize command as written already) so he is able to find the > link between the user and the alert. With this addional information he > is able directly interact and e. g. open exactly one mail or something > like this. > > The web developer also can decide to just not use those and pass a > fixed > address to the alertClass (http://maServer.com/myScript.php). > Technically Snarl would just make a find and replace with %ALERTID% > and > %UNIQUEID%. One example for let's say one user clicks on a mail - so > the > alertLeftMouse URL could be something like > > http://myServer.com/myWebApp/showMail.php?clientId=%UNIQUEID > %&alertId=%ALERTID% > > So the webdeveloper could look in his internal database which of his > users he gave the UNIQUEID 123 and which alert has been the one with > the > ID 456. > > In general Snarl will (when it displays a new notification) execute > the > URL stated in appReturnID to let the web developer know the ID > (also in > this case quite similar to the normal interface). The webdeveloper > would > most likely store this ID in some database to use it later on. > > There is a parameter called "open=true" and "open=false" which I would > also suggest. If it is set to true the URL would be used as if the > user > would have clicked on a link (so an new browser window open or > something > like this). If it is set to "false" Snarl would just open a connection > to this address but ignoring the response send back. > > These are just my first ideas - so let's discuss about that :) > > @Eli and @Edward: I put you on CC as you and Dealerflow are our fist > and > most important "customer" of the web API. If you would like to discuss > this ideas I would be happy if you would join our mailing list > sna...@li... > > Greetings > > Sven > > P.S. Having read once again through what I wrote I am not sure if we > even would need the UNIQUEID if the web developer chooses the alert ID > completly himself - but I decided to leave the text at it is to have > something where we can think about. ;) |