Smoking toooooo much PHP
Tuesday 23 September 2008
Remember the good old days where phpnuke was the worst code since
sliced cheese, and thousands of idiot's had installed in on their
server waiting to be hacked into..
Well, It's a bit like how I felt this week trying to solve my svg graphing issues..
A bit of background, In the last week I just pushed out the latest
version of our Anti-spam / Mail control application, the big new
feature was a beta version of the statistic's and analysis section.
Where we showed nice little graphs about how much work your staff where
doing and if they had really been sending jokes all day long or just
reading facebook spam
Open Flash Charts
While the database side , the design is quite interesting, I did not
really spend to much time thinking about the frontend - as I like to
keep that flexible (read throw away). So for the first beta I decided
to use Open Flash Charts. The current version is extremely well
designed, in terms of the chart generation consists of delivering a
JSON file to a static single Flash file. The JSON file sets the graph
type, and date etc..
It's very quick to set up and work with, and the graphs are quite
pretty, and a cutely interactive. And for our first beta it's just
about OK.
However for anything other than a beta, there are rather serious problems with it.
a) It's dog ass slow, to load, render on anything but a brand new overspec'd PC
b) The flash file is quite large, and yet another overhead to a already large application.
c) Having multiple Flash graphs on a single page, just makes the above two problems worse.
d) It depends on closed source tools (Actionscript compilers etc.) - Never a good idea.
e) Printing of Flash in firefox is broken (at least on linux)
or basically all summed up... Flash sucks
PlotKit
So after beta 1 was released to testing, I started the hunt for an
alternative. Since the 'correct' method to do graphs on the web is
really SVG, and as I like to shift all the pointless processing to the
end users PC. JavaScript to convert the data into a chart is really
the ideal solution.
Pretty high up on google's list is PlotKit, which has some really nice
demo's on the site, It depends on two other pieces of code, excanvas
(as nice self contained javascript file that handles SVG compatibility
issues with IE/FF/Safari etc.) and MochiKit.
MochiKit
Since MochiKit is none too small, and would add to my javascript
overhead, I thought I'd check out what it was, and see if it was really
needed. What I saw, was more "nightmare on nuke street".
The front page of the web site claims quite large "MochiKit makes
JavaScript suck less", That should be paraphrased, "only if you are a
Python nut-head" - otherwise it make your Javascript code into complete
jibberish. __self__, __new__, __screwed_up_language__ everywhere....
<big rant> The dumb f*** who wrote it decided that Javascript was
not Python, so they should try and make it's syntax as close to python
as possible. Ignoring the fact that Javascript syntax just solves
problems differently, it does not need fixing or even breaking to be as
badly designed as python.. </big rant>
Anyway after digging through the code to plotkit, and mochikit, I came
to the conclusion that they had developed a piece of code that was
completely unmaintainable or extend-able. So was forced to keep looking
for an alternative.
Quite a way down google's list (search svg javascript graph) I finally
found Plotr, Basically someone else had obviously looked at PlotKit,
and decided that Mochikit was just so ugly, that removing it from the
application was the only sane thing left to do.
What they chose rather than MochiKit, was Prototype, which in general
is considerably better than MochiKit. And basically removed all the
Mochikit dependancies and replaced them with Prototype. This made the
code quite a bit simple to read and understand, (they also added
comments), although I'm not to keen on this type of commenting, as I
find it add's noise, and makes the code less readable.
xxxx : function (/** some_type **/ xxxxx, /** another_type **/) {
Anyway, otherwise Plotr looks clean and simple.
** It looks like the author of Plotr as gone on to start Flotr -
another graphing library.. - did not notice that until I'd commited to
working with Plotr...
Prototype
What I wanted to do however was reduce the size of the Prototype
dependancy. So I started having a look at Prototype's internals.
Splattering the namespace
Unlike Ext, and Roo, Prototype's core creates quite a few global
properties, $, $R, $$, JSONSomething and Element which by the looks of
things are totally unnecessary, and make it difficult to work with
other frameworks (or potentially other code), This is downright bad
design, and could easily be rectified by putting almost all of those
under the Prototype.* object.
Along with this, there is quite excessive use of adding to Global
Prototypes, String.prototype gains about 20 extra methods, some quite
useful, or wrappers for compatibility, other seem more like features
for features sake, and should really be moved to a Prototype.String
object or just removed.
What make me wonder the most was the way that prototype adds properties
to HTML and DOM objects, $("xxxx") - get's does a getElementById(
"xxxx") and returns the DOM/HTML object overlaid with all of the
properties from the Element object. In Ext/Roo's 'Roo.get("xxx")'
method create's something like the 'Element' object , Roo.Element, it
puts the original DOM object in the return value ".dom" property. Hence
making documentation clearer and code considerably more managable. Not
so much of WTF did that method come from? when reading code.
Anyway - I managed to give Prototype a bit of a diet, so it's not so
much of a Namespace/bandwidth hog. You can download the lightwight code
here:
http://www.akbkhome.com/svn/javascript/plotr
Note the full bundle (protolite, excanvas + plotr comes in at 54K or ~
15K if you are serving javascript with the mod_gz library...
Just to prove it still works
http://devel.akbkhome.com/plotr/testplot.html
See here for the original code
http://code.google.com/p/plotr/source/browse/
Sunday 24 August 2008
Just a small update on roojs1 - I've added in-line comments to the RooJs1 documentation - so if you think a method or class is not well explained, add your comment, example code, or bug note right on the documentation. - Something I think makes a huge difference to the usability of code... Other small changes are also beginning to be added - including the fields property of a Roo.toolbar, and the new Roo.form.Hidden element, to make creating forms with hidden variables simpler. Anyway, rumors are swirling around that there is a recommendation to avoid ExtJS among certain linux distributors due to uncertainties and general lack of confidence in the license, it's continual changing and general poor behavior by Jack in not understanding the implications of the bait and switch changes. It also appears that Jack's Legal team are working harder than his coding team again, sending out threatening letters to people involved in various ExtJs2 derivative works. (which is the key reason I'm focusing on v1 - clear, definitive separation and licenses that do not allow for such shenanigans) While ExtJS2 offered some interesting new features. The significant change to the object rendering model, from my experience has been broken on every release prior to the GPL one, (and since I never tested it after that release, I suspect it's still broken). Other changes relating to a clearer heirachy of object model look like they should be a simple addition to ExtJS1, along with better support for non DOM element dependent constructors. Hence I think building on ExtJS1 appears to be a better long term move, and sounds like a few more are beginning to see that wisdom.
Tuesday 1 July 2008
Another update on progress on RooJS (the ExtJS v1 Fork) - Form's now have CSS, so the dynamic form examples work quite well
- The CSS was created by documenting how the existing examples where rendered in ExtJS - A document describing this was created (see form_design.svg in the css folder). Then that document was used to create a brand new CSS file. I believe this can be regarded as not breaking the copyright and having a reasonable reverse engineering process.
- the x-box borders are missing, although not critical
- the HTML editor needs to be fixed.
- I have done the design diagram for CSS of the menu's and will be working on that soon.
- The doc's are improving as well, The doc's appear to be listing all the correct elements now, future work will focus on tidying up the templates.
- Most of the improvements came from replacing the Walker code in the jsdoctoolkit so that it understands scope in a similar way to the compressor. I also had to add a few extra comments in the source to give the documentation tool a few hints.
- /** @scope Roo.somescope */ -- changes the scope in the documentation engine (as sometimes it just can not guess what the scope is.
- /** @scopeAlias avar=Roo.xyz.prototype */ -- adds an alias to the parser engine alias map, so when it sees 'avar', it will replace it with Roo.xyz.prototype
- The compresser is working well, someone asked on #roojs on freenode about using it for other code, including ExtJs2.0 - There should be no problem doing that - have a look at the bundle build file to see how to set up a builder for any project.
- One thing to note is that the compresser uses hints when it sees 'eval'. The YUI compresser basically turns off compression for a large chunk of the code if it sees 'eval', I've added code to pick up a comment before the eval statement:
- /** eval:var:abcd */ will turn variable compresion back on, and exclude 'abcd' from the list of variables to be compressed (use multiple eval:var:... statement on multiple lines to exclude multiple variables)
Anyway back to work tommorow, after celebrating (eg. doing nothing) the glorious reunification with the motherland day (HKSAR day)
Wednesday 18 June 2008
CSS hackers needed.Yes, the first test version of roojs1 is built and working you can have a look here to see the old ExtJS1 examples (which where sourced from a 0.40 release licenced under a BSD licence) http://www.akbkhome.com/roojs1/examplesWarning this may break occasionally as I do daily builds of the library Most of the main layout, windows, grid and tree work pretty well, but there are some problems with toolbars, menus and forms. Basically I could not find complete licence free sources for any of them. So if you know anyone who can create CSS for the missing parts (and can illustrate reasonably well that it was not based on the original ExtJS CSS) send them over this way. That will help RooJS2 as well, as the CSS is probably pretty similar. Have a look at http://www.akbkhome.com/roojs1/css/roojs-debug.css for details on the status of the css build.. A big leap forward in building a truely free high quality JS UI toolkit. Anyway onto my geeking techo fun.Rooscript compressorAs part of the whole build toolkit, I've ported the yui compressor to rooscript (the dmdscript based Javascript interpreter), The results are pretty good. The current output from the compressor is 8K less that the ~497K that ExtJS 1.1.1 files are (built I presume using yui compressor). Along with this, it's pretty easy to tweak, and remove Files and add your own application (eg. create an all in one javascript file for your application) Speedwise I've been trying to get the compressor to go faster (It normally caches the minification result to a file and can do a 'reparse' in arround 2 seconds, but for a fresh build it takes about 6 minutes to parse all the ~100 files in Roojs1 In the process of speeding it up, I've added a few switches to rooscript - -p for a very simple profiler (gives you the total time taken for all the opcodes exculuding call/new etc. in each function) along with how many times they where called.
- -U to turn on Unicode for strings, as I've disabled it by default, although I'm not that sure now, that it produced the speed hit that I thought it might. ** mostly affect things like xx.indexOf("\n")
- -d (to show all the opcodes as they run) - old but handy sometimes...
The code is reasonably simple, so If you have any great ideas on how to improve compression, it's extremely easy to test how well they work. (rather than the usual compile/run cycle that all the Java versions have) In looking at the resulting code, one simple opmization that I've started adding to RooJs is changing the constructor code in the object from Roo.data.Connection.superclass.constructor.call(this,....) to Roo.superC(this,....) and Roo.data.Connection.superclass.somemethod.call(this,....) to Roo.superM('somemethod', this,.....) I'm guessing that's could be ~ 2K of rather wastefull code removed.. Basically since the compressor is working now, I'm going to re-look at the Docs, and sort out the bug's in those - probably replacing the scoping code in jsdoctoolkit, with something closer to the ported yui compresser version.
Wednesday 11 June 2008
As I mentioned before, I've been busy getting the Ext Fork usable. still not quite there, but it's beginning to take shape.
RooScript
The fork I did of dmdscript (initially for gtk bindings) is being used as the core for all the build tools I'm working on for RooJS, so I though in honour of it's main use, I'll rename it rooscript (as it's a lot easier to google for than gtkDjs or whatever I came up with before..)
So here's a quick howto for building and testing the kit so far.
Rooscript building
First install gdc and subversion (I prefer it to dmd, as it's easier and quicker to set up and use)
#apt-get install gdc
#apt-get install subversion
decide where you want your code checked out to.
#cd /usr/src
#svn co http://www.akbkhome.com/svn/rooscript
#cd rooscript
#sh roo.lite.gdc.sh
you should hopefully now have /usr/bin/roolite
getting roojs1
#cd /usr/src
#svn co http://www.akbkhome.com/svn/roojs1
building the docsThe code is based on jsdoctoolkit, and modified to make better sense of RooJS's code. I did look at the Ext version of it, but they had used what looked like and older version of the jsdoctoolkit, so I just took some of the ideas from it. You can see a preview of the current roojs1 docs here
#cd roojs1
#roolite ../rooscript/examples/jstoolkit2/run.js \
-- Array.js Date.js Function.js Number.js Roo.js String.js \
-r Roo -t=../rooscript/examples/jstoolkit2/templates/jsdoc/ \
-d=docs/
building the js code (still under testing)
#roolite buildSDK/bundle_build.js -L../rooscript/examples/jstoolkit2
Ok, where is the project now.
- CSS/images have been recovered from an BSD licenced yui-ext-0.40 snapshot from here
http://demo.xteconline.com/system/js/builds/yui-ext.0.40.alpha1/
Most of the changes for 1.0.0 are just renaming the prefixes - The doc build is close, although still needs tweaking and checking
- The code builder is basic, (no variable replacement), but we do strip down close to dojo's hack to rhino, and I'm looking at yui's compresser for ideas on the variable stuff which should be quite simple.
- The css compresser has been ported to Javascript/rooscript, and should work, although I've not tested it yet..
- I'm pretty close to testing it by replacing the doc's backend to use Roo, rather than Ext.1.1.1
Tuesday 27 May 2008
Well, things are ticking away on the ExtJS forking project - There will be a official web site soon (I'm promised) - in the meantime head over to #roojs on freenode to see what's going on. On the global plan, this is what I've been looking at - I have found a copy of yui-ext 0.33, which was released under a BSD style licence, and includes all the CSS and Images. I've not got round to merging and testing it with the 1.1.1 code, but I can't see any major issues, as from my recollection 1.0 evolved from this.
- I got about halfway through adding all the javascript files (v1.1.1) to my subversion repo, along with modifying the headers to remove the licence link reference which is now irrelivant. The code can sit there until a shared repo becomes available.
- Made a dependancy list for the files (so that building specialized bundles should be easier)
- started testing a few javascript bundling tools (that work better than my simple tokenizer tool)
- Started looking at docs
The doc's turned out to be an interesting little intellectual challange, as I was not too impressed with jsdoc (the perl thing) Apart from being written in a "Write-only" language, it did not spit out anything resembling usefull docs from the extjs code. So I started looking at jsdoc toolkit (on google code) - It's dependancies are a bit annoying (java + mozilla js engine AFAIR) - but the thing is written in javascript - (very well designed) and looks like a better bet. My idea was to take this code, and use my dmdscript fork to run it and generate documentation without that java dependancy. My little dmdscript fork has a few benefits that make it very suited to this task - Built in File access, a built in tokenizer to start. And it's piss easy to extend. However it turned out to be a bit more complex than that. One of the major problems turned out to be that dmdscript uses digital mars's D's regex engine, which unfortunatly is seriously feature flawed. To the point that most regex's that you give it fall over badly. I did manage to hack in forgetfull matching (?:.....) but when I started finding quite a few more oddities, ([\s\S]+\s)? the whole task of trying to fix the code became to much, and I came to the conclusion that just ripping it out would be simpler. In it's place I've used the excellent pcre library by Phil Hazel (who also wrote one of the best MTA's out there.) The binding code for the pcre library was already available in dsource, hidden away in the dwin project, so after understanding the API for that, I've almost got to the point where a semi modified version of jsdoctookit can parse the Code. I still need to do some more fixes to the regex engein so it can render the templates. -But it's getting there.
Sunday 11 May 2008
I've started looking at forking ExtJS, after some considerable thought, I'm pretty close to the concluding that forking ExtJS is really option left, to retain the investment I've already made in it..
So, as I have a Zip file of 1.1.1 and it explicitly says that the Javascript code is Licensed under LGPL, (not ifs/ no but's) - I'm slowly putting the code into my subversion repo under www.akkbkhome.com/svn/extjs1 (*I'm looking at extjs1.1.1 as I have been using it and tend to prefer it, but there is nothing in the discusion below that precludes anyone helping/leadingwith the last extjs2 version that was released)
Now if this actually becomes a full fork (most forks fail BTW), It will need a bit of work, so If anyone is interested in helping out. I've no idea where this could go. But this fork ain't changing the license no-more...
The plan
I think there's quite a few things to do here... so Ideas or contributions.. -- feel free to email me, or just comment on this post. - At worst, it could form the brainstorming for anyone else actually doing this. (If you want to comment on if/should this be done - do it on my previous post, otherwise I will delete the comment)
The Code
- Tidy up Ext Js's source - see if it can be stored in one file per class, and have a simple classname->filename mapping... (eg. Ext.Dom in Ext/Dom.js) ** started..
- Sort out the CSS
- If Jack ever released any old CSS/images under a open licence (ext-yui source?) see if that can be used.?
- or Go through the classes and see what their requirements are for CSS
- Probably in batches - write a short document listing the required classes needed by the batch, enabling someone to contribute a CSS file that works.
- Posibly create enough CSS to make enough of it useable (probably with no images)
- Document image requirements (see above), then see if other open projects already have images that can be used? - otherwise see if someone want's to contribute themes..
- Break up Source into managable packages - Distribute ownership! - GIT or multiple SVN repos??
The Project
- Build infrastructure
- Create a command line tool that can compress then merge all the required components (and allows end users to do this)
- Allows source to be taken from multiple sources (so you can create builds with extensions / or without stuff you don't need)
- Forums
- Set up a mailing list! (and archived, with a search feature!) - Anyone know a good hosted one available? - or should I just go off and set the infrastructure here..
- No more 'premium' ... users! - equal, like open source is supposed to be!
- Manual
- Work out how to build a manual from the source!-- While Ext's manual is not bad, take the opportunitythis time do it right, and have a bug reporting / user comments on it....
- A name??/ - May need some thought...
The reasoning.
I have to admitafter some reflection to being pretty pissed at this change, ExtJs was useful in a number of ways, other than being a reasonably well written, the forums where search-able, so you occasionally found fixes to issues that you where having. The doc's where not to bad. etc.
But basically I've committed 1000's of hours of time to learning, and writing huge codebases that depend on ExtJS, under the basic premise that it was availably for Free, with the only Caveat that If I modified ExtJS, then I would have to give back those changes. "Quid Quo-pro" as they say.
The Change to GPL has altered that equation in such a radical way that If this was not a 'software' product, and was something physical. you would be down at the consumer council, and filing a class action against Jack for things like Breach of trust, financial gain by deception etc.And filing claims for the loss of your time, and the cost of replacing his library..
I have seen postings that appear to claim Jack plan's to 'send notice' to people using a fork, but as far as I can see, he released the Javascript code as LGPL, and from every reading I've seen of that, I have the absolute right to distribute the Javascript code, along with any modifications. - This is the purpose of the license!!! - so by claiming otherwise he is not honoring his own license, not a good omen for the future of ExtJs even under GPL!
I'm floating this, as a plan... - shout if you are interested/ have some ideas..?? - (or you can find real technical flaws - not FUD flaws please).
Wednesday 7 May 2008
I think that basically sums up my reaction to Jack's GPLv3'ing a library. For those who are not aware, As I was not, when I visited the extjs web site a few days ago to grab a copy of the old 1.1 version and found all references to download it had disappeared. Digging a bit deeper on the site, I started spotting a few comments about the new licensing.
While I can say that Jack as the author (of I presume most of extjs?) has the right to change the license to whatever he likes, I think he has probably just destroyed the project. I could not commit to writing new code with a "Library" that is GPL, unless I was working on a GPL project (which is unlikely at present - got bills to pay). And for commercial or spec projects, that are not turning revenues yet, I can't really justify my time in committing to develop stuff that may, or may-not be able to fund today's and whatever Jack feels like charging in the future for the non-commercial license.
I've seen too many people burned by this closed source dependencies that they build their businesses around, only to have the effective rental for their office yanked through the roof, and no other option than a huge effort moving to another library or software causing chaos.
All that said, I'm not sure if v2.0 and v2.1 are really worth bothering with anyway, I've tried them on 2 projects so far, and the general sense I get, is that compared to v1.1 they are a little finicky, and tend to produce slightly unpredictable results. Which is tempting me to stick with 1.1..
The problem I see though is that the community that has built up around extjs has been supported by quite a few handy tools, the wiki, the doc's and the rather nasty forum (which is a good way to waste time finding answers to issues). So I guess someone setting up a openext? (I saw something on the net about it) should probably sort out those issues first, then start solving the technical issues about how to replace all the images and css in extjs which where not previouslylicensed under LGPL.
I would hate to have to go looking at the alternatives again, So sticking with v1.1+ hacks may be the best long term plan for me anyway.
Thursday 13 December 2007
Heres the problem.. as soon as you start building large applications usings ExtJs your users say two things - Its slow to load
- Can you translale it into their language
The speed issues are mainly due to - Loading of many javascript files (With our currently quite small applications, there are still more than 30 single javascript files - one class per file, which can take over 10 seconds to load.)
- The javascript contains comments and whitespace (As I like to make my code readable and maintainable)
To address these issues, there are a few javascript compression tools out there, however, most have rather painful setup requirements, like getting java working, and are not very hacker friendly. Now that all my interface is embedded into javascript code, including all the button labels etc. l have been wondering for quite a while how I was going to translate the application and keep it up-to-date (in the Flexy template engine we extract the strings from the HTML, and have a tool that manages PO files based on them). Since this did not seem feasible for Javascript, I was begining to dread the thought of finding all the strings and wrapping them with something like a gettext type call. So it turned out my little dmdscript hacking may have some use... It took a small amount of hacking to add tokenizing support to dmdscript, by adding a new class for the javascript interface and few minor changes to dmdscript's internal tokenizer I got this little script to work. var data = File.read(fname);
var x = Script.tokenize(data);
for(var i =0; i < x.length; i++) {
if (x[i].tok == "whitespace") {
if (x[i].val.indexOf("\n") > -1) {
print("\n");
continue;
}
print(" ");
continue;
}
print(x[i].val);
}
print(";\n");
Basically it reads the file, then creates an array of objects, each one representing a token. (I should perhaps change the token to an integer and use Script.Token.whitespace as a constant... ). The script will basically strip all the whitespace and comments, and convert whitespace into either a line break or a space.. (as linebreaks are actually relivant in Javascript). The next issue was how to deal with language conversion. The code above can be used to test for strings by doing: for(var i =0; i < x.length; i++) {
if (x[i].tok == "string") {
println("got string: " + x[i].val);
}
}
So I came up with the idea of using the quote style to determine if a string needs translating. single quotes = does not need translating double quotes = a translable string. It was amazingly easy to change my existing code to do this, I could then generate a list of strings for each file, and output a JSON structured file which can be used to store the translations mapping. #djs ScriptCrusher.js -- --strings /tmp/Hello.js > /tmp/zh_HK.js
Would generate a file:
"Hello.js" : {
"Hello": "Hello",
"World": "World",
}
Which can be edited and translated. Then when Crunching the script up, it uses the map to convert strings from one language into another. eg. #djs ScriptCrusher.js -- --langfile /tmp/zh_HK.js /tmp/Hello.js \
> /tmp/Hello.zh_HK.js
#djs ScriptCrusher.js --/tmp/Hello.js > /tmp/Hello.en.js
(I've not done the merging of old/new yet, but it should be pretty trivial).
djs should be pretty simple to build: (requires gdc - available in Debian and Ubuntu + probably others)
#svn co http://www.akbkhome.com/svn/gtkDS
#cd gtkDS
#sh djs.gdc.sh
The full ScriptCrusher is here.. http://www.akbkhome.com/svn/gtkDS/test/ScriptCrusher.jsHappy Hacking..
Friday 19 October 2007
Most of the fun development projects had to be put on hold over the last few months, due to good ole paying projects.
ExtJS security holesThe majority of my paid projects are now using ExtJS, (and one has now used ExtJS 2.0, which is a definite improvement in both features and design). But I did run into what I considered to be a rather serious problem. ExtJS by design is a XSS nightmare... so be careful.
Basically the grid component and a few of the other components are designed to use JSON data comming from the server and render the data it recieves onto a styled HTML table. The problem I discovered, was that rather than using DOM.createTextElement() or similar to render the data it recieves. It uses innerHTML. So data is not escaped in any way prior to rendering onto the page.
It was discovered while testing one of my first major products, A complete Spam/Mail control solution, I discovered that it was not rendering email addresses <someaddress@example.com> , due to the <> characters. I dug into the code and realized the XSS hole, and posted it as a bug on the extjs forum.
Unfortunately it appears that rather than regarding this as a huge hole, they would rather trust developers to read the fine print in the documentation about rendering data to the screen. Personally I would be embarrassed by this attitude on my project.. 'security is someone elses problem'.. but I guess that's their problem... - I have to keep security patches for extjs handy....
GtkDjs updatesI finally got a short time yesterday to update the code in Gtkjs to use the latest dmdscript source, overlayed with my JS2 stuff and language binding add-ons. It builds and runs all the test code in the test folder, and Walter fixed the closure issues alot cleaner than I had...
I've also updated the 'downloadFiles.sh' script so that It fetches the correct language HTML files for the generator. It appears that gnome has moved all the documentation around. (It also means the generated code is more in sync with newer releases of Gtk and the many extensions.)
Mailfort teaser..As I mentioned above, I'm working heavily on a new product, Mailfort, anyone sending email to me, who I dont know, is likely to get a Identify confirmation email. We are currently testing with friends and family, along with a couple of companies, and hopefully more details will appear soon. But the teaser is that I've been working on Spam and mail control solutions for myself and a few clients, which has finally evolved in something generic enough that we can begin to sell. A number of my friends have been complaining about their Spam problems, so they are now slowly being introduced to the beta test product (with very positive feedback) so hopefully we will get the full website and product rolled out soon.
|
