- From: Christoph Dorn <christoph@christophdorn.com>
- Date: Thu, 30 Apr 2015 17:12:22 +0000
- To: smith@pooteeweet.org
- Cc: markus.lanthaler@gmx.net, public-linked-json@w3.org, henri.bergius@iki.fi
On April 30, 2015 01:12:03 am PDT, "Lukas Kahwe Smith" <smith@pooteeweet.org> wrote: >> On 29 Apr 2015, at 18:26, Christoph Dorn >> <christoph@christophdorn.com> wrote: >> >> I have created a summary of what I have in mind: >> >> https://gist.github.com/cadorn/6028e90c0d4d9eca514f >> >> I had been planning to implement something like this later this year >> anyway and would use this opportunity to start with something >> working and leverage existing communities to get where we want to go >> faster. I am looking to get an intent to integrate from at least one >> community (ideally Symfony) so we can get and keep momentum early on. > > Can you elaborate further with what you mean with breaking up create.js? > Right now create.js is basically architected to be the connection > between VIE.js, various JS editors (hallo.js, aloha.js, etc) and some > “MVC” layers (atm backbone.js): > https://github.com/bergie/create/blob/master/bower.json For me to make use of create.js I need a pure JS implementation that abstracts the whole page-editing problem no matter in which context it is used in. So create.js itself would turn into a virtual harness into which actual implementation plugins like viejs and backbone, jquery etc... are loaded. If I am going to do this work I will make create.js compatible with not only RDFa but arbitrarily annotated HTML and JS objects with pluggable parsers etc... The point is if you need to make a change to a system you can use create.js no matter what aspect you are working on. To me create.js (and more so the new pinf.wiki) project will be a tool to edit anything that can export some form of metadata and expose an API for editing. One of the hurdles to get started with create.js that I hope to remove is RDFa and JSON-LD etc... This tech is not necessary and to me a strict subset of the general editing problem that I hope to solve using a super easy to integrate and highly compatible solution. What is awesome about create.js is that it is already working in the RDFa/browser context so I have a solid starting point from which the concepts can be generalized. To make this new approach work I will re-architect the whole solution based on latest tech and experience to get the most gain. > So I am not sure if it really needs additional breaking up but rather > bug fixing, some modernizations here and there and most importantly > integration with some newer “MVC” frameworks. And finally some > new features like i18n, workflows etc. I am not interested in fixing bugs in the existing solution as I see it as having run its course (started several years ago, many issues, original author not available, no active contributors). It makes sense for people already using the component to fix bugs to keep things working but not for me. I personally would fix bugs after the reboot as many bugs will disappear due to a cleaner (more abstracted) design. I am proposing to dedicate at least 4 to 6 weeks to this initial effort which will allow me to get quite far. > That being said, Symfony CMF will have a two day hackday starting > tomorrow (http://cmf.symfony.com/news/cmf-hackday-may-2015) and I > will bring this up. I am quite confident that we would integrate any > work that moves create.js forward. My primary goal would be to KEEP COMPATIBILITY with the current integration BUT ADD MUCH MORE that may or may not be of use to Symfony. I believe Symfony CAN make use of the new features and would benefit but that is less important to me than Symfony swapping out its current usage with the new, more stable, tool. There will be plenty of opportunity to discuss the new features more and see a fit with Symfony. It would be great if you can discuss this more with others. Maybe we can get buy-in from a couple of devs early on and I can get some help! I really need someone from the Symfony community to assist at times to ensure everything stays compatible as my perspective and use-cases are quite different which I see as another bonus. Christoph
Received on Thursday, 30 April 2015 17:13:05 UTC