more detailed reply later -- Bassel Safadi | http://bassel.ws Skype: i.know.sy | Global: +1-323-545-3855
On Mon, Feb 27, 2012 at 6:47 PM, Bassel Safadi <[email protected]>wrote: > I use launchpad, and I really like the code you guys are writing. I'm > impressed by the amount of new features and bugs that got fixed. but I > think I can help re organizing stuff in aiki without touching others work. > in short words I want to organize the code to match my original charts ( > which I never posted) but want to post new ones. and yes that include some > radical rethinking of aiki and it doesn't touch others work. how is it > possible? you will see. > now why you care that much if you only care on doing the sites? the new > updated version of aiki will have all of the older features plus new ones. > and in order for it not to look like I'm deleteing someone else work I'm > doing it on separate branch. so please feel free to ignore my emails. until > you see the code is moved to the current trunk and bugs are closed, the > reason I'm sending stuff to the list is that actually when people are > working on stuff like Roger is doing they don't care much about launchpad. > only do the work at the end. > > actually it's not that I'm feeling losing control over aiki. but I want to > play with new stuff and there is nothing wrong with designing new panel and > new form engine as long as I'm not overwriting some one else work. now we > have engines. you think your markup is better way of doing stuff. and I > think enabling php will just allow users more freedom to do stuff, while > aiki it self save them a lot of time, and in my view enabling php inside > widgets will even save more time. fine let's create two engines. let me > create my engine on my branch then never use it what is wrong with that? > > I have time to follow up on launchpad, and btw I'm creating that chart you > are talking about. > > -- > Bassel Safadi | http://bassel.ws > Skype: i.know.sy | Global: +1-323-545-3855 > > > On Mon, Feb 27, 2012 at 5:15 PM, Jakub Jankiewicz <[email protected]> wrote: > >> I agree with that, I think that Bassel should check all blueprints and >> he should approve all of them, but I don't know if he will have time >> for that since there are some delays in response for him, and not >> every issue/blueprint/bug is commented by him. It would be nice if >> he's BDFL for Aiki and stuff would be implemented only if they will be >> approved by him. >> >> I don't know a tool for that but the way I think would be the best for >> managing ideas is to have some kind of graph with nodes that are >> features that are connected to other features and all stuff that are in >> aiki is in this graph >> >> something like ? >> / >> ---------forms ? >> / \ / >> / \ / >> AikiMarkup ----------- Widget System ----------- ? >> | -------/ \ >> | -----/ \ >> Engine ----/ \ >> ? >> >> it would be nice to have a tool that allow to create that kind of >> graf where in each node will be status (implemented, need rewrite, >> discussion etc.) and you click on every node and you will see blueprint >> and bugs related to that node. >> >> We can put that file into git and everybody will be able to edit it. >> >> I can create such graph in Inkscape (I think that there can be html >> inside svg so maybe we can put links to wiki in the graph) maybe it can >> be embeded into wiki page (since you can put svg inside html in modern >> browsers). >> >> >> The idea around Aiki was to help insert data into database via forms. >> But for me Aiki should a tool that allow to rapidly create nice web >> apps. So it need to be more powerful then just forms and widgets. I >> also thing that we should implement markup I propose and use it as >> default, because it allow to create such rapid applications. The idea I >> have with aiki is to have a tool that allow users to change thinker >> with everything, that's why my markup proposal may look complicated at >> first and using php will look simpler, but if we use php there will be >> no advantages using Aiki in first place. If there will be current forms >> in aiki which is pain to use users will be using php instead, and if >> they can use php instead why the hell they will want to use aiki. It >> will be more complicated the just use pure php. >> >> So what be left will be only Aiki API, so we end with a library which >> nobody will use. I personally don't see the reason, except maybe >> sentimental, to use Aiki if it only support php, the real power of Aiki >> will be the markup that will allow to create complicated things in few >> Aiki tags. >> >> It's nice that you can use widgets to create layout that it's split-up >> into chunks, but Aiki is suppose to allow to create applications, not >> help creating layout. Which don't see the reason why someone would want >> to use it to create such layout. Because you can create application much >> faster using just php (without any aiki). >> >> And another point is that Aiki should be also used by people that don't >> know php, and have small knowledge about programming, we should give >> those people bricks that will allow them to make powerful applications. >> If we give them php they will not use it. We can give powerful users a >> way to enable php if they can't do what they want using Aiki markup. >> >> But WE SHOULD USE AIKI MARKUP. For instance for me I don't see the >> reason to use php if I can use markup I propose, bacause I will be >> able to create things I want in 2 lines except 10. I can build almost >> every complicated code using few tags, and if there will be php I don't >> see the reason to use Aiki, maybe except to improve the sites that >> already use it, like OCAL or OFLB. >> >> On Mon, 27 Feb 2012 21:32:46 +0800 >> Christopher Adams <[email protected]> wrote: >> >> > Hey guys, >> > >> > Let's keep this cool. >> > >> > It makes me happy to even see Bassel's name in my inbox, given >> > everything that's going on. If he's back on this list more I take >> > that as a very positive sign for his well-being. :) >> > >> > My reading of the situation is that Bassel realizes we took the >> > infrastructure he built and kind of ran with it. He'd love to be able >> > to go back and make the foundation to build on a little more solid >> > and consistent with his original vision, which is to make Aiki great >> > and work the way it was meant to. However, that might be difficult to >> > reconcile with the current state of the project (including real >> > commercial needs for some of us) and the expectations and plans that >> > other more recent and active contributors have. >> > >> > I agree with jcubic that we should really stick to the bug tracker; >> > for now, that's Launchpad. We've pretty much short-circuited the >> > proposal–discussion–approval–implementation process. For my part I've >> > stuck to reporting bugs and suggesting blueprints, which of course is >> > not as helpful as actually implementing anything. Then again, some of >> > the recent amazing features have (seemingly) come out of nowhere, and >> > we don't want to be in the position of ignoring or discouraging >> > contributions. But I profess I'm ignorant of any broader Aiki roadmap >> > other than 'make it better'. >> > >> > So we all want to make Aiki better. We all have some good ideas. How >> > to manage that? I would like to see a clearer delegation of >> > responsibilities for how blueprints and bugs get discussed and >> > approved. Maybe for each part of the project we should designate one >> > person to approve blueprints for that part, and make it clear who is >> > assigned to work on it. I think Launchpad can handle this, if only we >> > can. :) >> > >> > Christopher >> >> -- >> Jakub Jankiewicz >> twitter: @jcubic >> www: http://jcubic.pl >> > >
_______________________________________________ Mailing list: https://launchpad.net/~aikiframework-devel Post to : [email protected] Unsubscribe : https://launchpad.net/~aikiframework-devel More help : https://help.launchpad.net/ListHelp
