voting results
Lukas Kahwe Smith
there doesnt seem to be a way to export the tickets, so I added a label "initial voting" and closed them. to view any of the tickets you can just use the following URL (replacing XXX with the ticket number):
http://github.com/symfony-cmf/symfony-cmf/issues/closed#issue/XXX
18. Reuseable content nodes (28 votes)
8. coreData, coreSearch/Index: separate frontend logic from storage/search layer (26 votes)
5. Version Control (25 votes)
11. coreLanguage: Translation Engine/Language Localization Engine (i18n/l10n) (24 votes)
3. corePublish: Build system integration to deploy to development, staging and production servers (22 votes)
40. sophisticated permission system (ACL, groups, roles) (22 votes)
1. multi-site support aka multi tenant support (21 votes)
2. RESTful API (18 votes)
34. workflows (17 votes)
24. different output modes formats (17 votes)
16. Plugin system (Being able to use symfony plugins out of the box?) (17 votes)
7. In-context/inline editing capability (custom defined areas) (16 votes)
22. centralized media/asset management (12 votes)
30. independence of website and administration interface (12 votes)
29. single sign on (11 votes)
6. support for different templating approaches (9 votes)
46. support admin panel for content editing (9 votes)
45. Site wide search (9 votes)
41. ability to scale the solution from small to large sites (9 votes)
42. easy to setup aka low barrier to entry (8 votes)
4. LDAP/Active Directory/Open Directory integration for user management (6 votes)
23. themeable Websites (same website, different look (see http://www.csszengarden.com) ) (6 votes)
32. independent caches (6 votes)
39. make sure that non CMS features can be used without using whatever storage API we use (5 votes)
47. allow user defined node types ( priviledged users can define how a content type is structured ) (5 votes)
54. Multiple user content editing locking mechanism (5 votes)
44. social media aka opensocial/opengraph support (4 votes)
56. Standards based web interface (4 votes)
57. Web Accessibility Compliance/Integration (4 votes)
28. support for long texts (3 votes)
33. multilevel caches (3 votes)
51. sandboxing support (2 votes)
25. Standalone frontend user interface (inline editing, common page setup etc.) (1 vote)
52. Easily to install and setup/FreeBSD port/self healing (1 vote)
50. MVC2 (0 votes)
A couple of tickets were created during the voting period:
58. Admin generator with extra features (2 votes)
66. coreEdit (0 votes)
65. coreIdentity (0 votes)
64. coreVideo (0 votes)
63. coreGallery (0 votes)
62. coreGL (0 votes)
61. coreImage (0 votes)
60. coreAuthentication (0 votes)
Since we dont really know how many people voted its impossible to tell what got a majority. I guess I should have put in a dummy ticket everybody should have voted on to get a total. Anyway, its still clear that a few items got more attention than others. Again we are looking for what should be core features that determine our core architecture, just because something didnt get a lot of votes doesnt mean it will not be done or at least possible to do.
So I would like to now ask you all to give your opinions about what conclusions we can get from these voting results about the architecture we should employ. Once we have agreement there, ideally we should be able to split up task areas to which people can commit themselves. That way each so created "team" can figure out the details of how they want to go about implementing them (maybe some teams will for example decide to use scrum?).
regards,
Lukas Kahwe Smith
sm...@pooteeweet.org
ryan weaver
Ryan Weaver
Lead Programmer Iostudio, LLC
http://www.sympalphp.org
http://www.thatsquality.com
Twitter: @weaverryan
Lukas Kahwe Smith
On 30.08.2010, at 16:36, ryan weaver wrote:
> I see these really as the core, and most of these should lead to some deeper discussions and research into other systems. Along the way, other sub-components will also spring up (e.g. minifying/combining assets, admin dashboard, support for WYSIWYG editors, etc etc etc), which I'm hoping will make for small bundles, many of which can be standalone to Symfony2.
yeah several tickets seemed like things that Symfony2 core should provide and we should make sure we participate there:
- basic ACL/auth infrastructure
- admin generator
- cache
- code packaging and deployment (content stuff will be our job obviously)
- javascript library management
Lukas Kahwe Smith
On 30.08.2010, at 16:36, ryan weaver wrote:
> Interesting results - some of the top vote-getters are a bit more complex and perhaps shouldn't be considered for the first go-around. When I think of a real solid set of tools to get more rolling towards building a content-based site, these come to mind (with approximate corresponding ticket number):
well one key option to consider at this point is of course if we want to base our work on JCR (i dont think we really need to decide just yet how strict we want to be) or try to come up with our own approach.
after the voting results i am convinced even more than before that JCR is the right direction. here are the top items (more than 20 votes):
18. Reuseable content nodes (28 votes)
8. coreData, coreSearch/Index: separate frontend logic from storage/search layer (26 votes)
5. Version Control (25 votes)
11. coreLanguage: Translation Engine/Language Localization Engine (i18n/l10n) (24 votes)
3. corePublish: Build system integration to deploy to development, staging and production servers (22 votes)
40. sophisticated permission system (ACL, groups, roles) (22 votes)
1. multi-site support aka multi tenant support (21 votes)
18., 8. 5., 40. lend themselves naturally to JCR
JCR makes none of the above items any harder either.
Maybe even most importantly it gives us an API spec to split up the work and gives us a reference implementation we can use. For example I agree that versioning might be tricky to do in our JCR backend in 1.0, but we could already implement it in the frontend for 1.0, giving users that need it the option of just using Jackrabbit.
Douglas Choma
Whenever I see Java, in relation to web projects, I get a little woozy... Java-based systems tend to feel overly engineered and overly complicated.
Lukas Kahwe Smith
On 31.08.2010, at 11:50, Douglas Choma wrote:
> I'm kinda late to the discussion. But from some quick Googling, it seems like JCR is pretty heavily tied to Java (for obvious reasons). Would CMIS be something to consider? It appears to be very language agnostic. I don't have experience with either technology, so please forgive my ignorance.
CMIS is a protocol definition where as JCR defines a real API. In this way CMIS could of course be a more high level alternative to base ourselves on but the two are not mutual exclusive:
http://dev.day.com/content/ddc/blog/2009/05/jcrcmiscomparison.html
However from reading the JCR spec I find it fairly understandable and not too oversized (there are a few features I am not sure if we want to use them, like the node type and event system we might want to largely keep in the client and not in the backend).
> Whenever I see Java, in relation to web projects, I get a little woozy... Java-based systems tend to feel overly engineered and overly complicated.
I used to be the same way until I started using Solr. Made me realize that there is stuff over there that is actually useful even if you dont just want to masturbate in front of endlessly deep class inheritance diagrams :)
Lukas Kahwe Smith
On 31.08.2010, at 11:57, Lukas Kahwe Smith wrote:
> However from reading the JCR spec I find it fairly understandable and not too oversized (there are a few features I am not sure if we want to use them, like the node type and event system we might want to largely keep in the client and not in the backend).
who here has spend a bit of time looking at the JCR 283 spec [1] who can chime in on this topic? did the spec seem understandable? did it address the needs adequately?
i am not really a CMIS expert, anyone can expand here?
plus are there any alternative "standards" or defacto standards worth following or using as guidance in light of the core features we have just voted on (like plone, etc)?
regards,
Lukas Kahwe Smith
sm...@pooteeweet.org
Jonathan Wage
who here has spend a bit of time looking at the JCR 283 spec [1] who can chime in on this topic? did the spec seem understandable? did it address the needs adequately?
On 31.08.2010, at 11:57, Lukas Kahwe Smith wrote:
> However from reading the JCR spec I find it fairly understandable and not too oversized (there are a few features I am not sure if we want to use them, like the node type and event system we might want to largely keep in the client and not in the backend).
i am not really a CMIS expert, anyone can expand here?
plus are there any alternative "standards" or defacto standards worth following or using as guidance in light of the core features we have just voted on (like plone, etc)?
[1] http://jcp.org/en/jsr/detail?id=283
Douglas Choma
Hi,
On Tue, Aug 31, 2010 at 4:19 PM, Lukas Kahwe Smith <sm...@pooteeweet.org> wrote:
who here has spend a bit of time looking at the JCR 283 spec [1] who can chime in on this topic? did the spec seem understandable? did it address the needs adequately?
On 31.08.2010, at 11:57, Lukas Kahwe Smith wrote:
> However from reading the JCR spec I find it fairly understandable and not too oversized (there are a few features I am not sure if we want to use them, like the node type and event system we might want to largely keep in the client and not in the backend).
I think the principles of the JCR are really important. Whether we follow their specification exactly or not, our implementation should follow the same principles and have the same purpose. Separate standardized layers.
Douglas Choma
Is it going to be possible to implement this all in pure PHP? Or will there be Java back-end components necessary? I'm definitely opposed to injecting any dependencies on Java. Aside from philosophical reasons, I think it will introduce a lot of complexity in hosting and deployment.
Pablo Godel
> Is it going to be possible to implement this all in pure PHP? Or will there
> be Java back-end components necessary? I'm definitely opposed to injecting
> any dependencies on Java. Aside from philosophical reasons, I think it will
> introduce a lot of complexity in hosting and deployment.
>
Hi Douglas,
This was discussed in this forum, and was agreed that java dependency
would not be mandatory, although until a pure PHP backend is
available, a java solution would be used in the meantime.
Pablo
Lukas Kahwe Smith
exactly. like i said for example in the beginning we might not implement the versioning stuff. or we might just implement the basic versioning and not the full versioning. however if we implement the JCR spec users that need these features right now at least have the option of simply deploying with a java backend, while the rest of the users can stick with a pure PHP solution. this is a big selling point for me, but obviously it only makes sense if we are sure we will be happy with JCR on a technical level too.
as i have stated from the get go, i am quite convinced that JCR is the right foundation for our efforts. i do want us to move forward and right now it seems like i am driving the discussion a lot, so i am hesitant to also be the one attempting to bring them to a conclusion.
so my question to all of you: do we need to discuss further? do we want to do a vote? do we generally feel comfortable with the idea that JCR will play a key role one way or the other?
in this case i would like to propose the following. matthias indirectly or directly tried to hit me over the head on twitter to remind me that its absolutely key that we come up with a clear concise mission statement for this project. lets make the concerted effort to define this mission statement by mid september for FrOSCamp.
we then task the people at FrOSCamp with writing a final proposal for a plan to get to 1.0 which we can then discuss and vote on this list. ideally getting us right into coding time by early october. potentially opening the door for another hack session with anyone attending symfony day (maybe we could get together on the 9th somewhere in cologne).
ryan weaver
Ryan Weaver
Lead Programmer Iostudio, LLC
http://www.sympalphp.org
http://www.thatsquality.com
Twitter: @weaverryan
Lukas Kahwe Smith
On 01.09.2010, at 14:57, ryan weaver wrote:
> In that light, you (Lukas) had mentioned (or so I thought) that the Flow3 folks were potentially having some problems with their implementation of JCR. What were you able to find out about that? If we went towards JCR, how similar would our efforts be to theirs and, knowing where they are now, how can that influence our decision towards or against JCR (i.e. how is JCR serving them thus far)?
not much unfortunately. this is why I made triple sure that one of the 2 flow3 core devs will come to FrOSCamp. good news is that thx to some smart allocation of marketing budgets I was able to pay for flight and hotel for Karsten, who leads the flow3 project together with Robert. so my plan is that we spend the morning until lunch learning from David Nüschler (he is the lead of the JCR specification itself) and Karsten about JCR in general and with PHP specifically. then in the afternoon we can work on coming up with a proposal for a plan for how to get Symfony CMF to a useable 1.0.
in my dream world, having Karsten there might even open up the possibility to identify areas where we can share code with flow3 (although here we also have to work out the license situation .. for us I think its clear we want to stick with the same license as symfony2 core).
Bruno Prieto Reis
Would you (or anyone else) please record this talk and all the others
on the FrOSCamp related to this project so that the people (including
me) that will not be there will be able to listen, possible watch, and
know what happened ?
BTW: I´ve read a few chapters of the JCR (1,2 and 2) and also passed
my eyes over all the spec and I agree with you all that it´s a good
path to follow. I only have my doubts about how to map a so granular
model (node trees with properties, values) to a relational DB without
loosing performance with complex queries. Maybe the ODB will play a
important role here... but this is a discussion for a near future, I
believe.
Lukas Kahwe Smith
On 02.09.2010, at 15:31, Bruno Prieto Reis wrote:
> Would you (or anyone else) please record this talk and all the others
> on the FrOSCamp related to this project so that the people (including
> me) that will not be there will be able to listen, possible watch, and
> know what happened ?
Ok, i can check if we can get some video recording setup.
> BTW: I´ve read a few chapters of the JCR (1,2 and 2) and also passed
> my eyes over all the spec and I agree with you all that it´s a good
> path to follow. I only have my doubts about how to map a so granular
> model (node trees with properties, values) to a relational DB without
> loosing performance with complex queries. Maybe the ODB will play a
> important role here... but this is a discussion for a near future, I
> believe.
an RDBMS is definitely not the ideal place to store tree structures. that being said, NoSQL also has issue there as while you can just nest documents into other documents, its obviously not feasible to store the entire node tree in just one document. however these are not impossible to solve issues. both RDBMS and NoSQL do allow for modeling if tree structures. however its obvious to me that for different cases you might want to use different algorithms.
for example for a blog post and the nodes directly related to that blog post, you might even want to store everything in one document inside an ODM. however obviously for a node representing a page inside a page tree, this would obviously not be feasible. i am not sure if JCR provides for some way to hint the structures that we can sensible use here. if there needs to be some magic inside the JCR store that automatically converts things to a different tree algorithm in case the tree gets too deep for example or what approaches should be best taken there.
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
Lukas Kahwe Smith
On 02.09.2010, at 15:37, Lukas Kahwe Smith wrote:
>
> On 02.09.2010, at 15:31, Bruno Prieto Reis wrote:
>
>> Would you (or anyone else) please record this talk and all the others
>> on the FrOSCamp related to this project so that the people (including
>> me) that will not be there will be able to listen, possible watch, and
>> know what happened ?
>
> Ok, i can check if we can get some video recording setup.
ok we have some video recording stuff. i dont think we can get a live stream going though. also if we just record the discussions, then there will be a couple hours worth if fairly hard to follow video.
so one of my co-workers proposed that we do 2 interviews over the course of the day. that way there will be some context to whatever decisions we come up and a more personal touch, which probably helps especially for the understanding the more controversial decisions.
as for IRC, we can definitely make an effort to include people via IRC. i can also try if a skype phone conference works. but i cannot really make a guarantee there if it works. in case this slows us down too much, i would honestly rather focus on letting the people work who are physically present. none of the decisions we make are going to be final obviously, so there will still be plenty of opportunity for the rest to participate. i also welcome anyone to submit idea's for how to best get to 1.0 beforehand.
ok?
ryan weaver
Ryan Weaver
Lead Programmer Iostudio, LLC
http://www.sympalphp.org
http://www.thatsquality.com
Twitter: @weaverryan