Re: [E-devel] edje: emit signal to 'GROUP' part

2009-05-04 Thread Jose Gonzalez
   pieterg wrote:

 On Saturday 02 May 2009 22:08:27 Gustavo Sverzut Barbieri wrote:
   
 On Sat, May 2, 2009 at 4:15 PM, pieterg piet...@gmx.com wrote:
 
 On Saturday 02 May 2009 19:26:00 Gustavo Sverzut Barbieri wrote:
   
 On Sat, May 2, 2009 at 1:28 PM, pieterg piet...@gmx.com wrote:
 
 How about if we allow the use of group:signal as signal name?
 I've implemented this as a test, and it works like expected.
   
 I don't know if it would break things, possibly you better do check if
 there is a part with that id and it is GROUP in order to avoid
 breaking existing apps that may use : in the name.
 
 OK, good point. So something like this perhaps?
   
 mostly. I liked your patch, but committed a slightly different version
 that does only one strchr() and uses strdupa() instead of strdup() as
 strings live for short time and are rather small.

 I also changed it to use the part name, not the source name as usually
 you can have more than one part using the same group/source. See
 attached example.
 

 Indeed, I was in doubt about whether to use the part name or the source 
 name, changed it to the source name the last minute. But in order to allow 
 the same group to be swallowed several times, we need to use the part name, 
 as you say.
   

   That ability was part of what was intended in the original design. There
were other apects that I recall discussing with rephorm at the time.. but
can't recall just exactly what those were anymore.

   There was one other fairly simple extension I do recall we discussed
at the time: we wanted to add to edje (along similar lines) the ability
to embedd other descriptively defined 'objects' via loadable modules and
the basic swallow mechanism.

   This was to add a new OBJECT part type, whose main decription would
have two attributes, say module and src.

   Thus for example one would have as part of an OBJECT part description:

 module: module_name;
 src: some uri;

   The 'module' would refer to an edje object module which would simply be
a loadable lib which has a few basic interfaces. For example, besides the usual
module init/shutdown funcs, they must also expose an add function of the form:

Evas_Object *(*add)(Evas *evas);

and a file set function of the form:

void (*file_set)(Evas_Object *obj, const char *uri);

and this is what the 'src: some uri;' would refer to for being 'set'.

   Further refinements of this are possible, but just with this one can
extend edje in some interesting and non-trivial ways which many can use.
For example, most any smart class you can define that would allow for the
smart objs it creates to have a file 'set' on its instances... say eg.
an svg module, where one sets .svg docs as the files.. or say some
kind of 'gadget' module where you set a .edj file as a theme... or many,
many such kinds of things. Very similar of course to the html object tag
and other such.

  Since these modules can do much more than use 'sandboxed' scripts, it might
also be nice to add an edje api func to disable loading any object modules,
or 'unknown' ones somehow, etc.

   This is all fairly straightforward to implement, if desired.


Want more out of life?? Fast track your career with an online degree.
http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTKL6dobI0ICbt3elKJ0bxR9DVnlLJFOZtlrQNbZUgKsdcQ9mpncC8/

--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] edje: emit signal to 'GROUP' part

2009-05-02 Thread Gustavo Sverzut Barbieri
On Fri, May 1, 2009 at 4:30 PM, pieterg piet...@gmx.com wrote:
 I'm relatively new to edje, been picking most things up rather quickly.
 There's one thing I would like to accomplish, but haven't managed yet:

 How can I emit a signal to a 'type: GROUP' part, to be received by a program
 in that group?

not possible. I see what you want and I wanted that when i discovered
type:GROUP by rephorm. We even tried to implement it, but it triggered
infinite loops and more generically we could not find out a good
semantic for it. You can google for our discussion 2 years ago or so.

A solution that could help is to create an embryo variant for emit(),
like emit_group() that would take the PART:id and do the work, this is
actually easy to do and you can try.

Raster can say more about it, but maybe we'll need a way to catch
signals directly from embryo, like signal_callback_add and get the
arguments from embryo as today we can catch them with program {}, but
not able to get the emission/source from embryo.   I say that raster
might say more about it since he was doing the embryo-only objects
and that should cover this case.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] edje: emit signal to 'GROUP' part

2009-05-02 Thread pieterg
On Saturday 02 May 2009 16:42:33 Gustavo Sverzut Barbieri wrote:
 On Fri, May 1, 2009 at 4:30 PM, pieterg piet...@gmx.com wrote:
  How can I emit a signal to a 'type: GROUP' part, to be received by a
  program in that group?

 A solution that could help is to create an embryo variant for emit(),
 like emit_group() that would take the PART:id and do the work, this is
 actually easy to do and you can try.

That sounds like a usable workaround. I'll have a look and see if I can 
implement that.

Rgds, Pieter

--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] edje: emit signal to 'GROUP' part

2009-05-02 Thread Atton Jonathan
Calaos has the same problem a long time ago, now we use some macros. It
generate more parts in the file than a group inclusion but it works :)

2009/5/2 pieterg piet...@gmx.com

 On Saturday 02 May 2009 16:42:33 Gustavo Sverzut Barbieri wrote:
  On Fri, May 1, 2009 at 4:30 PM, pieterg piet...@gmx.com wrote:
   How can I emit a signal to a 'type: GROUP' part, to be received by a
   program in that group?
 
  A solution that could help is to create an embryo variant for emit(),
  like emit_group() that would take the PART:id and do the work, this is
  actually easy to do and you can try.

 That sounds like a usable workaround. I'll have a look and see if I can
 implement that.

 Rgds, Pieter


 --
 Register Now  Save for Velocity, the Web Performance  Operations
 Conference from O'Reilly Media. Velocity features a full day of
 expert-led, hands-on workshops and two days of sessions from industry
 leaders in dedicated Performance  Operations tracks. Use code vel09scf
 and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel




-- 
Regards.
--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] edje: emit signal to 'GROUP' part

2009-05-02 Thread pieterg
On Saturday 02 May 2009 16:42:33 Gustavo Sverzut Barbieri wrote:
 A solution that could help is to create an embryo variant for emit(),
 like emit_group() that would take the PART:id and do the work, this is
 actually easy to do and you can try.

How about if we allow the use of group:signal as signal name?
I've implemented this as a test, and it works like expected.

Constructions such as

script {
 emit(languageselection:languages_fade_in, );
}

and 

action: SIGNAL_EMIT languageselection:languages_fade_in ;

are possible with this.
And it slightly follows the

source: groupname:partname

convention, which we already have.

--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] edje: emit signal to 'GROUP' part

2009-05-02 Thread Gustavo Sverzut Barbieri
On Sat, May 2, 2009 at 1:28 PM, pieterg piet...@gmx.com wrote:
 On Saturday 02 May 2009 16:42:33 Gustavo Sverzut Barbieri wrote:
 A solution that could help is to create an embryo variant for emit(),
 like emit_group() that would take the PART:id and do the work, this is
 actually easy to do and you can try.

 How about if we allow the use of group:signal as signal name?
 I've implemented this as a test, and it works like expected.

 Constructions such as

 script {
  emit(languageselection:languages_fade_in, );
 }

 and

 action: SIGNAL_EMIT languageselection:languages_fade_in ;

 are possible with this.
 And it slightly follows the

 source: groupname:partname

 convention, which we already have.

I don't know if it would break things, possibly you better do check if
there is a part with that id and it is GROUP in order to avoid
breaking existing apps that may use : in the name.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] edje: emit signal to 'GROUP' part

2009-05-02 Thread pieterg
On Saturday 02 May 2009 19:26:00 Gustavo Sverzut Barbieri wrote:
 On Sat, May 2, 2009 at 1:28 PM, pieterg piet...@gmx.com wrote:
  How about if we allow the use of group:signal as signal name?
  I've implemented this as a test, and it works like expected.

 I don't know if it would break things, possibly you better do check if
 there is a part with that id and it is GROUP in order to avoid
 breaking existing apps that may use : in the name.

OK, good point. So something like this perhaps?
Index: edje/src/lib/edje_program.c
===
--- edje/src/lib/edje_program.c	(revision 40487)
+++ edje/src/lib/edje_program.c	(working copy)
@@ -816,6 +816,40 @@
Evas_Object *obj;

if (ed-delete_me) return;
+
+   if (strchr(sig, ':'))
+ {
+   /* the signal contains a colon, split the signal into group:signal, and deliver it to group */
+   int i;
+   char *splitsig = strdup(sig);
+   char *group = splitsig;
+   char *colon = strchr(splitsig, ':');
+   char *newsig;
+   if (colon)
+ {
+*colon = '\0';
+newsig = colon + 1;
+for (i = 0; i  ed-table_parts_size; i++)
+  {
+ Edje_Real_Part *rp;
+ rp = ed-table_parts[i];
+ if (rp-part-type == EDJE_PART_TYPE_GROUP
+  rp-swallowed_object
+  rp-part
+  rp-part-source
+  !strcmp(rp-part-source, group))
+   {
+  Edje *ed2 = _edje_fetch(rp-swallowed_object);
+  if (ed2) _edje_emit(ed2, newsig, src);
+  free(splitsig);
+  return;
+   }
+  }
+ }
+   /* we have no group by that name, continue delivering the signal to our own group */
+   free(splitsig);
+ }
+
emsg.sig = sig;
emsg.src = src;
_edje_message_send(ed, EDJE_QUEUE_SCRIPT, EDJE_MESSAGE_SIGNAL, 0, emsg);
--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] edje: emit signal to 'GROUP' part

2009-05-02 Thread Gustavo Sverzut Barbieri
On Sat, May 2, 2009 at 4:15 PM, pieterg piet...@gmx.com wrote:
 On Saturday 02 May 2009 19:26:00 Gustavo Sverzut Barbieri wrote:
 On Sat, May 2, 2009 at 1:28 PM, pieterg piet...@gmx.com wrote:
  How about if we allow the use of group:signal as signal name?
  I've implemented this as a test, and it works like expected.

 I don't know if it would break things, possibly you better do check if
 there is a part with that id and it is GROUP in order to avoid
 breaking existing apps that may use : in the name.

 OK, good point. So something like this perhaps?

mostly. I liked your patch, but committed a slightly different version
that does only one strchr() and uses strdupa() instead of strdup() as
strings live for short time and are rather small.

I also changed it to use the part name, not the source name as usually
you can have more than one part using the same group/source. See
attached example.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
collections {
   group {
  name: inner;
  parts {
 part {
name: part;
type: RECT;
mouse_events: 0;
description {
   state: default 0.0;
   color: 255 255 255 255;
   rel1 {
  relative: 0.0 0.0;
  offset: 0 0;
   }
   rel2 {
  relative: 1.0 1.0;
  offset: -1 -1;
   }
}
description {
   state: state 0.0;
   inherit: default 0.0;
   color: 255 0 0 255;
}
 }

 programs {
program {
   name: prog;
   signal: sig;
   source: src;
   action: STATE_SET state 0.0;
   target: part;
}
 }
  }
   }

   group {
  name: main;
  parts {
 part {
name: bg;
type: RECT;
mouse_events: 0;
description {
   state: default 0.0;
   color: 0 0 0 255;
   rel1 {
  relative: 0.0 0.0;
  offset: 0 0;
   }
   rel2 {
  relative: 1.0 1.0;
  offset: -1 -1;
   }
}
 }

 part {
name: a;
type: GROUP;
source: inner;
mouse_events: 0;
description {
   state: default 0.0;
   rel1 {
  relative: 0.0 0.0;
  offset: 0 0;
   }
   rel2 {
  relative: 0.5 0.5;
  offset: -1 -1;
   }
}
 }

 part {
name: b;
type: GROUP;
source: inner;
mouse_events: 0;
description {
   state: default 0.0;
   rel1 {
  relative: 0.5 0.0;
  offset: 0 0;
   }
   rel2 {
  relative: 1.0 0.5;
  offset: -1 -1;
   }
}
 }

 part {
name: event_a;
type: RECT;
mouse_events: 1;
description {
   state: default 0.0;
   color: 255 255 0 255;
   rel1 {
  relative: 0.0 0.5;
  offset: 0 0;
   }
   rel2 {
  relative: 0.5 1.0;
  offset: -1 -1;
   }
}
 }

 part {
name: event_b;
type: RECT;
mouse_events: 1;
description {
   state: default 0.0;
   color: 255 0 255 255;
   rel1 {
  relative: 0.5 0.5;
  offset: 0 0;
   }
   rel2 {
  relative: 1.0 1.0;
  offset: -1 -1;
   }
}
 }

 programs {
program {
   name: pa;
   signal: mouse,clicked,1;
   source: event_a;
   action: SIGNAL_EMIT a:sig src;
}

program {
   name: pb;
   signal: mouse,clicked,1;
   source: event_b;
   action: SIGNAL_EMIT b:sig src;
}
 }
  }
   }
}
--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. 

Re: [E-devel] edje: emit signal to 'GROUP' part

2009-05-02 Thread pieterg
On Saturday 02 May 2009 22:08:27 Gustavo Sverzut Barbieri wrote:
 On Sat, May 2, 2009 at 4:15 PM, pieterg piet...@gmx.com wrote:
  On Saturday 02 May 2009 19:26:00 Gustavo Sverzut Barbieri wrote:
  On Sat, May 2, 2009 at 1:28 PM, pieterg piet...@gmx.com wrote:
   How about if we allow the use of group:signal as signal name?
   I've implemented this as a test, and it works like expected.
 
  I don't know if it would break things, possibly you better do check if
  there is a part with that id and it is GROUP in order to avoid
  breaking existing apps that may use : in the name.
 
  OK, good point. So something like this perhaps?

 mostly. I liked your patch, but committed a slightly different version
 that does only one strchr() and uses strdupa() instead of strdup() as
 strings live for short time and are rather small.

 I also changed it to use the part name, not the source name as usually
 you can have more than one part using the same group/source. See
 attached example.

Indeed, I was in doubt about whether to use the part name or the source 
name, changed it to the source name the last minute. But in order to allow 
the same group to be swallowed several times, we need to use the part name, 
as you say.

Thanks for committing this.

--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] edje: emit signal to 'GROUP' part

2009-05-01 Thread pieterg
I'm relatively new to edje, been picking most things up rather quickly.
There's one thing I would like to accomplish, but haven't managed yet:

How can I emit a signal to a 'type: GROUP' part, to be received by a program 
in that group?
The other way around is easy, a signal from source groupname:partname is 
received just fine. But edje_cc doesn't allow me to use 
the groupname:partname convention in a target, or as a program name. And 
I assume that this isn't just a limitation of edje_cc.

My experience is that edje data collections will grow quickly, and it will 
become more and more difficult to keep track of the whole thing, as it 
grows.
Putting different screens and even certain parts of windows into separate 
subgroups really helps to keep things tidy.
But these groups need to communicate with eachother.

A possible workaround is emitting a signal to the application code, and 
letting the application emit the signal to the (sub)group.
I'm doing that now, so I can at least get the desired functionality.

But that's not very nice, especially when those signals are not meant for 
the application to act upon, just for graphical effects in the 
userinterface.
Changing the userinterface would mean changing the application, to 
accomodate all new signal connections between the various parts.
Note that I don't just mean changing a theme, my goal is to have a 
userinterface which controls not just the way things look, but also the way 
things work, which steps the user has to take, and in which order.

Another possible way around this is not to use seperate groups for the 
different windows / window regions, so every component can signal every 
other component in the same large group (and perhaps just put different 
building blocks into different files, to keep a bit of overview)

So my question, again, is it possible to interact with a subgroup? Emit a 
signal to it, or perhaps run a subgroup program directly?
If not, what would be the prefered way to structure large edc's?

Rgds, Pieter

--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] edje: emit signal to 'GROUP' part

2009-05-01 Thread Jose Gonzalez
   pieterg wrote:

 I'm relatively new to edje, been picking most things up rather quickly.
 There's one thing I would like to accomplish, but haven't managed yet:

 How can I emit a signal to a 'type: GROUP' part, to be received by a program 
 in that group?
 The other way around is easy, a signal from source groupname:partname is 
 received just fine. But edje_cc doesn't allow me to use 
 the groupname:partname convention in a target, or as a program name. And 
 I assume that this isn't just a limitation of edje_cc.

   

   I can't recall a damn thing about this anymore, Brian Mattern (aka. 
rephorm) did
the work for this. Maybe others can help you here, but it's likely not 
too difficult
to implement what you want edje to do here.. if indeed it's not possible 
to do so
already.

 My experience is that edje data collections will grow quickly, and it will 
 become more and more difficult to keep track of the whole thing, as it 
 grows.
 Putting different screens and even certain parts of windows into separate 
 subgroups really helps to keep things tidy.
 But these groups need to communicate with eachother.
   

   That they should. It would also be nice if you could define more complex
structures, like 'widgets', declaratively and have them be 'swallowed'. 
Or be
able to fully extend edc to have groups as specific kinds of declarative 
types,
or any number of other interesting things.

   Some work related to this was done by Hisham on the etk based evolve
(a lib and simple gui builder based on an edc kind of declarative format for
defining etk widget types, which allowed you to reference edje theme 
groups).
Perhaps ewl, or the new elementary widget set, might have something
like that in mind as well - don't know.
 
 A possible workaround is emitting a signal to the application code, and 
 letting the application emit the signal to the (sub)group.
 I'm doing that now, so I can at least get the desired functionality.

 But that's not very nice, especially when those signals are not meant for 
 the application to act upon, just for graphical effects in the 
 userinterface.
 Changing the userinterface would mean changing the application, to 
 accomodate all new signal connections between the various parts.
 Note that I don't just mean changing a theme, my goal is to have a 
 userinterface which controls not just the way things look, but also the way 
 things work, which steps the user has to take, and in which order.
   

   Well, that's kind of the 'holy grail' of gui programming isn't it.. 
How to be able
to easily define the look and behavior. In this case via some 
declarative format
plus minimal logic or scripting. Or at least, to do as much of this as 
possible.
   Hence there are things like css, html, xul, mxml, xaml,.. and 
assorted scripting
languages, and a variety of gui builders/designers around those. Big 
important
stuff in the gui world at large it seems.

   I recall seeing something about a Mozilla based desktop-shell called 
Pyro
for which you could actually use html,xul,css, ... (plus some 
javascript) to define
the actual desktop - very interesting.
   Edje/edc itself is somewhat limited right now -  the group part was 
an attempt
to allow for some amount of re-usability and for some amount of 
tree-structuring
that was similar to the external 'swallow' model, but I can't recall how 
much of
it was finished. There may also have been some extension to embryo to have
something like an on_load function... can't recall for certain though.

   More is definitely needed.. whether as part of edje itself, or via 
some other lib,
or whatnot. And of course gui builders/designers are likely the only 
real way that
most people would ever be able to do large amounts of complex stuff.

 Another possible way around this is not to use seperate groups for the 
 different windows / window regions, so every component can signal every 
 other component in the same large group (and perhaps just put different 
 building blocks into different files, to keep a bit of overview)

 So my question, again, is it possible to interact with a subgroup? Emit a 
 signal to it, or perhaps run a subgroup program directly?
 If not, what would be the prefered way to structure large edc's?

 Rgds, Pieter
   


Earn a degree in Criminal Justice and work as a Police officer.  Click here for 
more info.
http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTEe1V7Gxz3fMuXs4f0BZi87LdhfLT8axjJrtQqqQyHx1mFudSNVvy/

--
Register Now  Save for Velocity, the Web Performance  Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance  Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
___