First an technology/platform should be selected on which the frontend will be written. Possibilities so far:

- Flash
- Silverlight
- Java Applets, Java FX & family
- HTML & JavaScript

Because Flash is widely distributed across the net - I've started mocking up the prototype right there, but after 1 day of trials, performance improvements & etc I ended up with something which wasn't quite good as I expected:
http://wizartworx.com/hSourceEditorInstance.air (there is used optimized version of http://code.google.com/p/as3syntaxhighlight/ )

As you can see the end result isn't fast enough to support hundreds of source code lines. So eventually flash platform isn't suitable for implementation of robust fast performance code editor. So I questioned myself - what platform eventually will go further than its current state. Silverlight is great, Java too, but all of them actually are plugins and "workarounds" to features which web browser does not has. And with the ongoing HTML5 integration this "workarounds" actually won't be needed anymore. And a proof for that is these path links which I've gathered during the research process:

demos:

• http://3.paulhamill.com/node/39
• http://www.whatwg.org/demos/2008-sept/color/color.html
• http://xant.us/ext-ux/lib/ext-3.0.0/examples/desktop/desktop.html
• http://jeko.free.fr/megapong/
• http://demo.nextapp.com/echo3csjs/
• http://glimr.rubyforge.org/cake/redesign.html

some highlight libs & editors/components:

• http://mihai.bazon.net/projects/javascript-syntax-highlighting-engine
• http://code.google.com/p/google-code-prettify/
• http://marijn.haverbeke.nl/codemirror/
• http://shjs.sourceforge.net/
• http://guillaume.bort.fr/textile-editor/index.html

frameworks:

• http://sproutcore.com/
• http://prototypejs.org/
• http://sizzlejs.com/
• http://www.extjs.com/
• http://www.gapjumper.com/
• http://labs.adobe.com/technologies/spry/home.html

And many many more implementations on the pathway.

Conclusion

I'll leave this section without stating my own opinion, but one is for sure -> HTML5 will change the way how browsers interact with the web, not by themselfs but generally as how developers implement it.

So as been curios what is going on with the head line of development turned to Github & Google Code . Sadly didn't found anything covering my expectations (the same situation as DAssistA though). And while still been curious how other people handle working together in easy enough convenient way decided to give a try to the history:

Project management is the discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives. It is sometimes conflated with program management, however technically a program is actually a higher level construct: a group of related and somehow interdependent projects.

And while quick-cross-referencing the information there I stumbled upon the Extreme Programming which in that light is simply told as:

Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.

Interesting thought we use "agile methodologies" all the time, even in a more huge time-laps like in "Phased" methodology used a couple years ago. Or as it is now - everyone looking forward after XP and its frameworks (Scrum). One thing which made me not believing in those methodologies as immediate future for project _development_ is my everyday work using them. Also looking towards the incoming era of open cloud - source it is fairly reasonable to see that those tools & methodologies need more... But what?

And then moved to the next one PRINCE2 - methodology having only one year live. Well I'll leave it without comment... But this (which is older than me) grabbed my imagination - PERT.
PERT is not a methodology as the above mentioned onces, nor it is something new - but all in all it is what every single project been developed nowadays is:

commonly abbreviated PERT, is a model for project management designed to analyze and represent the tasks involved in completing a given project.

So once the project has its tasks, team, goals & all other pre-requirements it can start. And then things get sometimes very ugly - complex tasks relationships, human errors causing reoccurring tasks to became issues and a lot more of the same manner as you may be experienced once in awhile been involved in project development. Naturally projects & their management accordingly their development will evolve, so I questioned myself - "how?".

Took me a while to dig all those, but anyway they all have a same thing and miss another.

• streber/Project overview - streber
• Features | Open Atrium Customized Home Page Increases Small Business Productivity - OnePlace
• qdPM - Project Management, Time Tracking, Support Tickets, Open Source
• Project.net | Project.Net Tour
• DeskAway - Online Project Collaboration Features - Milestones, Tasks, Issues, Time Sheet, Upload Files, Docs and more...
• Open Workbench - Home
• TaskFreak! web based task manager and todo list, project management made easy
• OpenProj | Serena Open Source and Hosted Project Management Software
• Project management, requirements, collaboration, and task software: Endeavour
• Gtdagenda.com
• Unfuddle: Subversion Hosting, Git Hosting, Bug and Issue Tracking
• TimeWhale - Online Time Recording, Tracking and Management Software
• LiquidPlanner - Online project management software, scheduling, collaboration, tracking
• Quick tour of COMINDWORK - Online Project Management, Knowledge Sharing and Collaboration Free Software

So how should look like Issue/Task Management System for projects (not programs) in the future? What should be its features, requirements & _purpose_? Will it help people to communicate more easily over complex inter-related work to be done?

All those questions are still open to me. But one is for sure -> the picture should change...
Mine proposal is to visualize those as graph I'm totally against tables & lists (after all the UI will change as the input goes multi-touch isn't it?).

I've lost around 2 hours to understand why Flexbuilder can not debug Flex4 based AIR project, when suddenly I've opened project's ".actionScriptProperties" file and found what really was happening preventing me with all of the possible errors found during such setup...

So the problem is in the target version which was used (Flex Builder for Linux is generating air template projects for flex 4.0.0 sdk using 'old' .actionScriptProperties file, a template one you can get from the attached template-workspace-0.1-bla.tar)

And here are the essential parts which needed me quite a lot of time to figure out (may be one day this all will be one click setup?)

0. Ubuntu 9.04 32 bit with java installed (there are a lot of tutorials, mine is just to select its as package via Applications-> Add/Remove UI)
1. You need 32bit Eclipse 3.3.x (extract, mine is /home/outbounder/eclipse)
2. You need Flex Builder of course (run as normal console application ala "ALT+F2 - > xterm")
3. After that you need all the sdks for development:
3.1 flex 4.0
3.1.2  (optional) I still work on flex 3 projects, so sdk 3.4 is needed)
3.3 Air SDK is needed, where strangely for one day I encountered several changes resulting in such download page at this moment (2010.03.17, 2:07 am)

4. Extract flex 4 sdk to install location of flex builder (mine destination  is at /home/outoubnder/flexbuilder/sdks/4.0.0)
5. Extract AIR sdk on top of flex 4 sdk destination folder
6. Rename adl & adt (those are located at the ./bin folder of the flex 4 sdk destination folder) to adl_lin & adt_lin

7. Fire up eclipse, add flex 4 sdk (more info here)

8. You can use the above mentioned template workspace for flex3/4 +/- AIR projects

9. You'll need to follow also the instructions for installing Adobe Flash Player 10 — Debugger Version. as well and for even faster coding -> snippets

And now I can dream of abstract GUIs managing complex data relationships...

I've been talking in real for ABN - written bellow  - so many times, that it is final time to me as developer to enter all the thoughts, road blocks and something more in digital form.

The entire purpose of the following is to get the overall picture 'sticked' as much as possible  and make it transparent for further improvements. Take in mind that what is stated bellow is subject to change during next meeting follow ups, as it was modified so far. See while I've been talking to people so far, we all had targeted and solved one or another problematic aspect on the concept been discussed.

Don't get scary of the long text bellow, this is the short version

Let's start with Active Bot Network concept in one sentence...

Active Bot Network is distributed network of single purpose applications.

Ok, nothing new you may say. And what's that thing which makes my live easier?

- basing software development on ABN lowers the time needed for completing single product feature.
- 'simplifies' application's implementations, thus lowers the risk of issues related to its purpose.
- enables evolutionary software development beyond using only agile methodologies.

Hmm. What? Well, that is natural reaction to the above three points. But let me present them in more light....

One of the most often used backend features in mine applications are "user data storage" &  "sms/email sending". So if you follow me - you'll already thought about the case that those two features  can be `sticked` into separate applications:

- userstorage application
- sms/email sending application

And expose their functionalities to other 'high-end'  applications via any possible medium: HTTP, XMPP, AMF, RAW SOCKETS, & anything else which you can think of.

Ok, so far nothing new also. But please do not stop reading, follows something really crazy:

Imagine having not 100, but 10 000 such simple purpose applications. Some of them proxies to existing services, some of them as they are currently provided as 'services'. Add in the picture decentralized application registry. And make all this realtime.... From which point lets assume that applications are just acting as 'bots' in ABN. Let's say that every bot can have more than one instance, and place in option that there will be "bots talking to bots" (Peter Neubaurer).

Yes, that is internet nowadays. Nothing new here in terms of technology(JBoss & many more), only a switch in the concept... Currently internet has hundreds such 'application bots', some of them running in application servers, others in separate services, clouds & etc... All they are targeted in solving given particular problem of technology (most often resulted as end-user products like Twitter).  See from this point on, most of the Readers may give up reading...

But for those who are still here - we'll take a sharp turn and assume that:

Everything in technology is possible, depending only on how much time it will take.

Or in other words let's forget about the pin-point technical details, they all will be referenced later in. And focus on the concept as stated before Active Bot Network. What everytime was needed to mention at this point during my talks is that current software development trends follows something like natural evolutionary pathway, where in the beginning programmers played with algorithms, later with libraries and now most trending is with services. What comes out from all of this is that it comes natural to start building those applications talking to each other in even more complex scenarios of those like master application using child ones (userstorage, sms/email sending, & etc.). And because one brilliant mind said:

“Make things simple, but not simpler”(Albert Einstein)

It is more easy, cost & effort effective to focus on building more stable common features wrapped as bot applications and scale up on reusing in hierarchical manner. When in addition to that design principle of simplicity (also reflected in current design patterns well used across various technologies) is provided realtime context based eco system of underlying and overlaying bot applications, then things get really chaotic as Reader may suspect already. And chaos may be considered highly unappreciated behavior in human build network, but if you look at internet at higher level -> it is the chaos itself, therefore it is better to get used to it... Now lets take in the second aspect of nature/evolutionary based software applications:

"Only the strongest will survive"

And here we all stay in front of next main question (again but in other form) as may Reader already noticed - "What is my share of joining such network?". Well the same as the other's who are developing applications based on such ABN concept - opportunity to expand, scale and most important interconnect.

Then there are coming some more questions as well, but before answering them, for which the Reader should excuse me - Next on the ABN facts stack comes in place the ability not only to create first hand application bots but also bot managers. While keeping things simple it is natural to be able to support any possible device which is constructed with networked communication. Such ability implemented wisely (don't forget that only the 'strongest' will survive) will empower ABN as decentralized eco system. Reader may already doubt about my own well-awareness and what the f**k I'm talking about exactly... But please continue reading because of the fact that:

To whom I've presented the idea in full potential, always agreed that it is possible, but...

But things are really simple. And because of that ground base fact ABN can be build only on evolutionary approach, where sharing of knowledge & opportunities is the most important aspect of participation in there. Hmm. Does it makes sense now? Well take in advance the following ideas:

- active bot network can be build not only by individuals, but also by companies, teams, organizations & others.
- there will be always people for one thing, and people for other, as well as bot application serving one purpose, and bot application for other.
- concurrency is the natural  way of seeding the strongest (the most stable) bot applications. Therefore and application versions of such exists.

About the questions, which I've promised to answer - > please forward them here http://activebotnetwork.tumblr.com/ask, that way I'll be able to respond in the most rational and transparent way. Sadly here I'm not able to list all of those questions and answers to which we all finally contributed to form the overall ABN's concept as clear as possible. But what is stated above means every single word. And what wasn't covered - will be in the near feature. What is essential to be understood right from the beginning is that:

Without global eco-system contribution and awareness ABN won't be possible.

As much active people start thinking and contributing, as fast things will start moving, where no momentum will be lost in leveraging across technologies... Only the most usable per given purpose will survive.

Something to share:
http://activebot.net/forum
http://activebot.net/wiki
http://activebot.net/wiki/abn/projects

http://www.pluraprocessing.com
http://linkedprocess.org
http://neo4j.org
http://www.rabbitmq.com/
http://haxe.org

Ps. Whatever mistakes had been made, or wrong assumptions stated - they are all mine unless otherwise mentioned. If you find something inappropriate please contact me to get it fixed asap.

What you may expect from it in the near future is actually what ABN concept stands for: a lot of re-usable apps talking to each other... But now - coming with modular & scalable API for apps/bots communications through several channels first to be supported:
- REST
- XMPP

... next to come - who knows

I have to note that the repo includes some external tools which licenses I've didn't found/included yet, where this will be done for the next major release of DAssitA's repo 0.1.

Let's get started:
Minimum requirements:
- Windows 7 OS
- Adobe AIR runtime installed

You can download the repo_0.0.7

And here are the steps required to get it moving:

0) unzip the downloaded repo to a folder where appropriate (mine setup is that the repo is extracted at D:\pd-repo\)
1) install haxe compiler with batteries included from here
2) install last revision of ActionPdmlToolbar
3) install last revision of PdmlEditor
4) to be able to use Svn module - install slick subversion command line client
5) add to your apache  new virtual host pointing to your unziped repo root folder using similar to this syntax:

<VirtualHost *:80>

    ServerAdmin webmaster@pdrepo.dev
    DocumentRoot <<YOUR PATH TO THE REPO's ROOT FOLDER>>
    ServerName pdrepo.dev
    ServerAlias pdrepo.dev
    ErrorLog pdrepo.dev-error_log
    CustomLog pdrepo.dev-access_log common
</VirtualHost>

Note that pdrepo.dev servername alias should not be changed, otherwise ActionPdmlToolbar & PdmlEditor won't boot.

6) add the following entry in C:\windows\system32\drivers\hosts file:

 127.0.0.1 pdrepo.dev

7) enable mod_neko2 for your apache by placing the following in httpd.conf:

LoadModule neko_module "C:/Program Files (x86)/Motion-Twin/neko/mod_neko2.ndll"
AddHandler neko-handler .n

place the ndll file from <<repo>>/haxe/org/dassista/tools/Prc.ndll to your neko directory

And that you go.
To test is DAssitA is installed properly try the following:

1) launch ActionPdmlToolbar
2) open explorer to <<repo>>\haxe\org\dassista\_pdmls\
3) drag the file compile.pdml to the ActionPdmlToolbar
4) double click on the compile.pdml entry from the action toolbar and see that there are no exceptions or anything scary outputed (usually compiling DAssitA itself requires around 5 to 6 secs and should ouput only empty lines)

1) developer A builds a simple 'mailman' bot, responsible only to sending given mail content + attachments using specified mail server to specified end recipient(s).
2) other developers build bots based on the 'mailman' bot just after its initial version is released.
3)  developer A find issue/adds new feature to the mailman bot, thus makes a new version of it (the mailman bot evolves)
4) all other developers need either to use the old version of the mailman bot or to change/fix their bots to be able to use the new version.

The problem is that if bots are kept alive in separate versions - then we'll develop as the nature had been developing our world for million years until now (even today it still does) -> all bot 'branches' based on old versions of bots will eventually fail or will need to evolve to be able to keep them-selfs stable...

But as we are building the context where bots will reside, therefore we can make it to shorten to minimum the evolving time & amount of 'dead' bot branches...

There will be an open realtime discussion about that in skype today (25.11.09) at 21:00 BG/FI time. If you want to participate just place a comment on this post or contact me at skype : b.filipov , so upon the time we can gather all in one conversation.

DAssistA shell can do only one thing: invoke & pass any command line arguments to specified multi-module.
DAssistA rest can do only one thing which is the same as the shell, but made in rest-like context via http request/responses

ActionPdmlToolbar can do only two simple things:
- list  available (cached) pdmls & triggers their parsing/execution also providing feedback as pop up window.
- list available runtime modules returned by ModuleInfo impl. & trigger their execution.

PdmlEditor can do only one simple thing:
- edit pdml files. Currently it supports drag & drop operations for all available runtime modules returned by ModuleInfo impl.

So far so good.
There are still some little issues which should be fixed before new repo release can be made + engaging auto-update features for both PdmlEditor & ActionPdmlToolbar.

One of the biggest challenges so far is to build 'universal' application while keep the code needed to minimum, where this is so far hard near to impossible  even for so simple things like fast & cross-platform command line invokes... But all this soon will be past

repo_0.0.6

Note: you'll need haxe compiler installed to be able to engage the system

Here is simple steps to be followed (later will make them automatic):

1) you need a repo(swarm) & haxe compiler installed
2) type within the repo "parser.bat haxe.org.dassista._pdmls.setup" - this will install PdmlEditor
3) start DAssistA's restService by typing within the repo "restService.bat"
4) Use  PdmlEditor as separate application for editing pdml files.

Next to come:

PdmlToolbar - separate quick access to avarage pdml files
ProjectModeler - separate project modeling tool (just the top of the iceberg indeed)

Graph oriented data persistence is just the beginning of AI

That's all it goes...