Research and Development 1/^Archief/2009-2010/06/Pilot/Vergaderingen
Vergaderingen
De belangrijkste grote vergaderingen uitgeschreven ongeveer, de eerste 2 zijn zonder notulen gemaakt, de vervolg vergaderingen zal ik (Kevin) notuleren.
Vrijdag, 13-03
Wij zijn bij Leon begonnen om 11 uur, op de computer kamer. Daar zijn wij gaan denken over wat en hoe we nu precies willen met dOPE.
De punten die we hebben behandeld zijn:
- Structuur van dOPE
- Modulair
- Virtual opslag versus hard opslag (lang punt)
Structuur van dOPE:
Hoe willen wij ons systeem opbouwen, dat was de vraag. Na een tijd overleggen vonden we unaniem dat we met modules moesten werken die de gebruiker zelf mag
bepalen welke en hoe hij ze heeft. Een beetje zoals iGoogle, dat vonden we omdat er zo ook modules kunnen maken die haast door niemand worden gebruikt maar misschien
voor sommige projecten essentieel zijn. Ook vonden we dat het dragable vrij plaatsbare modules moesten zijn zodat iedereen hun eigen work space kan opzetten.
Iedereen heeft zo maximale controlen over zijn eigen project heeft.
Met dat zelfde idee vonden wij dat modules ook weer moeten gecustomeerd worden, dus toen besloten wij dat je in modules plugins kan steken. Een voorbeeld is bijvoorbeeld:
De Editor module ondersteund normaal alleen html en php syntax higlighting (en andere features misschien) maar door een module kan hij ook de features en highlighting doen
voor een exotische taal die iemand misschien wilt gebruiken in het project.
De modules die wij nu in dOPE willen hebben standaard zijn:
- Documentatie: Een documentatie portal, een soort "wiki" voor je project waar je alle documentatie, en misschien zelf wel uml schema's en andere dingen in kan zetten
- Editor: Een editor die highlighting doet en andere features zoals misschien smart parsing van classes (dus functie lijsten laten zien die je kan aanroepen in de class,
of auto completement of samenwerking zodat je tegelijk in het zelfde moment kan werken)
- Project manager: Een project lijst waar je project kan beheren en bestanden aanmaken, svn beheer
- Settings module: Wij weten nog niet zeker of de settings module in de project manager komt of een losse module, settings kunnen zijn settings over het project tot en met hoe je de line regels wilt hebben (tabs of spaces)
- Rechten module: Niet zeker of deze dan in settings module moet komen, hier kan je mensen uitnodigen en rechten geven voor welke bestanden en of mappen of dele van project of gehele projecten mogen wijzen of lezen of bijden (chmod)
Virtual opslag versus hard opslag:
Een van de features die wij willen is het gebruik maken van andermans project in je eigen project, dus als iemand een handige library heeft geschreven voor een project.
Dan kan je zeggen dat je dat project bij jou project wilt gebruiken. Nu vonden wij daar allemaal iets van over hoe je dat moet doen. Je wilt server ruimte besparen
Dus de heletijd kopieen maken is niet heel handig. Maar om allemaal virtual paden te maken en dat ook iets mee te doen in de svn, want die projecten moet je ook weer
willen uitchecken van de svn en dan wil je alles hebben dus ook het "virtuale project". Na veel overleg hebben we besloten om:
- Als je een bestaand project wilt gebruiken in je eigen project "fork" je het project naar en plaats je die in de svn naast je eigen project, dan is het virtuele opgelost
Waarom omdat het virtuele heel veel problemen mee nam, en dit is ten eerste stuk makelijker te implementeren dit bied je ook de mogelijk om veranderingen in te voeren in het geinclude project
- (Mogelijke feature)Het auto updaten van een project, wij weten welke project van waar komt als je zo een fork maakt, dus wij kunnen een auto update maken (dat is niet heel moeilijk)
- De increase in server opslag zal in deze stage van het project nog verwaarloos zijn, en als dit later echt een groeiende IDE word dan kunnen wij nog altijd een virtueel project include maken.
Dinsdag 16-03
Vergadering dinsdag de 16/03:
Wij zijn via skype gaan praten over hoe we nu precies het systeem form willen geven, al deze punten kwamen naar voren en waren wij bijden content mee (en achteraf goedkeuring door ben), de keuzens zijn gemaakt door te beslissen of wij dat zo fijn zouden vinden. Wij zijn de gebruikers base van de applicatie. - Een framework systeem in php
- Maken van libraries die je dan kan gebruiken in je modules - Een paar zijn er: db acces (singleton), gui drawing functies, drag drop via javascript, rechten settings, read/write functies voor bestanden, en nog meer dingen die elke module wel eens zou kunnen gebruiken - De modules zelf hebben allemaal zowiezo een communicatie functie, zo dat je kan communiceren tussen modules en vooral dat je kan communiceren met modules op andere computers binnen je project - De modules generen zelf de html en javascript die ze moeten gebruiken zelf, maar het "windows" gedeeld, dus een dragable bar een sluit en minimaalzeer boxje (bij wijze van spreken) word gegenereed door het framework. - De modules kunnen ook plugins in die features uitbrijden. (dmv van class overiding en uitbrijden van call tables (callbacks))