You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by Peter Kelly <pe...@uxproductivity.com> on 2015/03/11 17:56:58 UTC
Prototype web app, and Editor API
Unfortunately I still haven’t found time to begin putting together the foundations of a proper web version of the Corinthia app, but I dug up an old version of a prototype I was experimenting with quite some time ago (before the code became open source). You can check it out here:
http://web-demo.uxproductivity.com
Username/password: demo/uxwrite
Sometime in the next few days I hope to massage this into a cleaner format and get something into the repository. But if you’re keen to start looking into this now, doing a view source on this will give you an idea of how the web app could be implemented.
Note that this demo just uses a pre-defined HTML document; there’s no server-side logic, ability to load & save files, or any integration with DocFormats. This was basically a proof of concept, but I think could give us some ideas for a starting point. Note also this is based on an old version of the editor code.
Also, I’ve created a page on the wiki to document the API exposed by the Editor library (that is, the code in Editor/src) - see https://cwiki.apache.org/confluence/display/Corinthia/API+reference. These are the public functions intended to be used by a native app or other UI (e.g. browser-based). The prototype I mentioned above has the editor library and document being edited in an <iframe>, with all of the UI logic kept entirely separate from the library. Jan, I understand, is currently working on the necessary bindings for C++/Qt to talk to the library.
I’ve just listed the functions so far without documentation. I’ll get to this as time permits, but if you’re looking for something relatively easy to get started on, some of you might like to have a look through the code and contribute documentation. All of the APIs are covered by the test cases (Editor/tests/*) so you can see examples here of how they are used.
--
Dr. Peter M. Kelly
Founder, UX Productivity
peter@uxproductivity.com
http://www.uxproductivity.com/
http://www.kellypmk.net/
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Prototype web app, and Editor API
Posted by jan i <ja...@apache.org>.
On 11 March 2015 at 17:56, Peter Kelly <pe...@uxproductivity.com> wrote:
> Unfortunately I still haven’t found time to begin putting together the
> foundations of a proper web version of the Corinthia app, but I dug up an
> old version of a prototype I was experimenting with quite some time ago
> (before the code became open source). You can check it out here:
>
> http://web-demo.uxproductivity.com
>
> Username/password: demo/uxwrite
>
> Sometime in the next few days I hope to massage this into a cleaner format
> and get something into the repository. But if you’re keen to start looking
> into this now, doing a view source on this will give you an idea of how the
> web app could be implemented.
>
May I recommend you add it as consumer/webappl or webedit
I happen to have had a peak preview of the source, and I do not think a
general massage will help a lot, this is enough to give the interested
reader a good understanding.
But it would be good to have it in our repo.
>
> Note that this demo just uses a pre-defined HTML document; there’s no
> server-side logic, ability to load & save files, or any integration with
> DocFormats. This was basically a proof of concept, but I think could give
> us some ideas for a starting point. Note also this is based on an old
> version of the editor code.
>
> Also, I’ve created a page on the wiki to document the API exposed by the
> Editor library (that is, the code in Editor/src) - see
> https://cwiki.apache.org/confluence/display/Corinthia/API+reference.
> These are the public functions intended to be used by a native app or other
> UI (e.g. browser-based). The prototype I mentioned above has the editor
> library and document being edited in an <iframe>, with all of the UI logic
> kept entirely separate from the library. Jan, I understand, is currently
> working on the necessary bindings for C++/Qt to talk to the library.
>
Now we are talking....my version is still a bunch of yellow stickers.
Basically we will extend/massage this to be the "official" DocFormats API.
and yes, I work heavely on Qt, even though right now I am side tracked with
64bit compile which Qt requires...so as a nice side effect we will have a
64bit windows version.
>
> I’ve just listed the functions so far without documentation. I’ll get to
> this as time permits, but if you’re looking for something relatively easy
> to get started on, some of you might like to have a look through the code
> and contribute documentation. All of the APIs are covered by the test cases
> (Editor/tests/*) so you can see examples here of how they are used.
>
Short documentation would be nice, and then as we "design" the real API we
need a lot more documentation.
thanks for your good work.
rgds
jan i.
Ps. Maybe we should really think about not using html mail, this mail
passed the moderator, due to a high spam count (because of html).
>
> --
> Dr. Peter M. Kelly
> Founder, UX Productivity
> peter@uxproductivity.com
> http://www.uxproductivity.com/
> http://www.kellypmk.net/
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
Re: Prototype web app, and Editor API
Posted by jan i <ja...@apache.org>.
On 12 March 2015 at 12:15, Peter Kelly <pm...@apache.org> wrote:
> > On 12 Mar 2015, at 1:26 am, Franz de Copenhague <
> franzdecopenhague@outlook.com> wrote:
> >
> > I just built an django example to prototype the server-side. It uses the
> CKEditor but we can replace it by DocFormats web editor
> >
> http://django-ckeditor-franzdecopenhague.c9.io/admin/demo_application/examplemodel/2/
> > username/password: admin/admin
> > It is running in a developer python server, let me know if you cannot
> see the link.
> > JD
>
> This looks fantastic.
>
> Now that I’ve committed the proof of concept editor I’ve written to the
> repository (which has a very limited UI compared to what you’ve shown),
> would you like to have a go at this?
>
> Actually, is the UI there from CKEditor, or your own? The former is not
> Apache licensed which might be problematic. We’ll need to figure out what
> our/Apache’s policy is for using third-party frameworks in web apps.
> There’s a lot of good ones out there and it would be nice to be able to
> re-use them if licensing conditions allows.
>
> At any rate, I think a topic we should begin discussing is UI design.
> There are existing word processing/writing tools to draw inspiration from.
> Lets hear everyone’s ideas.
>
I agree with you, but I am also a bit concerned. I would like to see the
functionality working in parallel to UI discussions. Maybe I am just
allergic at the moment to too much talk and too little productivity :-)
rgds
jan i.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
Re: Prototype web app, and Editor API
Posted by Andrea Pescetti <pe...@apache.org>.
jan i wrote:
> On 12 March 2015 at 16:05, Franz de Copenhague wrote:
>> http://django-ckeditor-franzdecopenhague.c9.io/admin/demo_application/examplemodel/2/
Just a quick mail to say that I've taken a look at both demos and they
look very nice, even though of course I would need the time to look at
the underlying architecture to assess where we are in Corinthia.
> We cannot
> however use e.g. GPL or BSD, the reason is that they limit downstream
> projects from e.g. making a derivative and sell it...something we at ASF
> really like when it happens.
Minor clarification that adds to the list from Dennis: it is not about
"selling" a derivative, but it is about the freedom to choose whatever
license (open source or proprietary) for it. This is a subtle
distinction, but it may be relevant for a project like Corinthia.
Regards,
Andrea.
Re: [dfwebserver] API
Posted by Peter Kelly <pm...@apache.org>.
> On 13 Mar 2015, at 1:17 am, jan i <ja...@apache.org> wrote:
>
> On 12 March 2015 at 18:52, Franz de Copenhague <
> franzdecopenhague@outlook.com> wrote:
>
>> I am thinking about what server features are required by the editor.
>>
>> 1. Upload a document
>>
>> 2. Get the HTML abstract of the document
>>
>> 3. Push the edited HTML representation in the document
>> 4. Upload new images and other embbed objects in the edited HTML
>>
>> 5. Download the document
>>
>
> These are the very basic features, but I think you also need:
> 6. Get a list of all styles (so the user can add styles)
> 7. Generate new table of index, subject index etc.
>
> Peter published a list of functions that the current JS needs:
> https://cwiki.apache.org/confluence/display/Corinthia/API+reference
>
> I would expect we need to have all of them implemented (hopefully a bit
> more generic).
Actually these are all the functions the current JS code *provides*. What it does need are the following callbacks:
debug(str)
error(error,type)
addOutlineItem(itemId,type,title)
updateOutlineItem(itemId,title)
removeOutlineItem(itemId)
outlineUpdated()
setCursor(x,y,width,height)
setSelectionHandles(x1,y1,height1,x2,y2,height2)
setTableSelection(x,y,width,height)
setSelectionBounds(left,top,right,bottom)
clearSelectionHandlesAndCursor()
updateAutoCorrect()
All of these are called asynchronously, and actually the calls aren’t made by the library themselves, but are added to an array of “messages” - see Editor/src/Editor.js for details. The reason I implemented callbacks in this way was (at least at the time) the UIWebView class in iOS did not provide any way for JS code to invoke Objective C code, which is what needed to happen in all of the above cases. So after every call to one of the API methods listed on the wiki, you’re supposed to call Editor_getBackMessages(), and you get an array of arrays, each indicating the function name and parameters.
As you can see, the set of callbacks is very small; the majority of work is in implementing all the logic that invokes the already-provided APIs from the wiki. Also the outline methods above are optional, and only necessary if you wish to provide a real-time document map (see the first screenshot at http://static.uxproductivity.com/media/). The same goes for autocorrect.
For the web-based editor, I suggest we implement a wrapper class for the API which, for each function, calls the real implementation version and then invokes Editor_getBackMessages() to invoke registered callbacks. Otherwise the UI code is going to be really awkward and we’ll likely forget to do it in some places. I can help get this going and will try to find some time to do so soon.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: [dfwebserver] API
Posted by jan i <ja...@apache.org>.
On 12 March 2015 at 19:38, Franz de Copenhague <
franzdecopenhague@outlook.com> wrote:
>
>
> ----------------------------------------
> > Date: Thu, 12 Mar 2015 19:17:03 +0100
> > Subject: Re: [dfwebserver] API
> > From: jani@apache.org
> > To: dev@corinthia.incubator.apache.org
> >
> >
> > If you got to https://cwiki.apache.org/Corinthia and create a login,
> then I
> > will give you write karma to our wiki pages.
> >
> > rgds
> > jan I.
> >
>
> Done!
>
likewise, logout/login and you have edit/create permission.
have fun
jan i.
>
> My username is franzdecopenhague
>
> franz
RE: [dfwebserver] API
Posted by Franz de Copenhague <fr...@outlook.com>.
----------------------------------------
> Date: Thu, 12 Mar 2015 19:17:03 +0100
> Subject: Re: [dfwebserver] API
> From: jani@apache.org
> To: dev@corinthia.incubator.apache.org
>
>
> If you got to https://cwiki.apache.org/Corinthia and create a login, then I
> will give you write karma to our wiki pages.
>
> rgds
> jan I.
>
Done!
My username is franzdecopenhague
franz
Re: [dfwebserver] API
Posted by jan i <ja...@apache.org>.
On 12 March 2015 at 18:52, Franz de Copenhague <
franzdecopenhague@outlook.com> wrote:
> I am thinking about what server features are required by the editor.
>
> 1. Upload a document
>
> 2. Get the HTML abstract of the document
>
> 3. Push the edited HTML representation in the document
> 4. Upload new images and other embbed objects in the edited HTML
>
> 5. Download the document
>
These are the very basic features, but I think you also need:
6. Get a list of all styles (so the user can add styles)
7. Generate new table of index, subject index etc.
Peter published a list of functions that the current JS needs:
https://cwiki.apache.org/confluence/display/Corinthia/API+reference
I would expect we need to have all of them implemented (hopefully a bit
more generic).
If you got to https://cwiki.apache.org/Corinthia and create a login, then I
will give you write karma to our wiki pages.
It would be nice to have a page, that describes the functions (and
interface) between server and client and the wiki is a better place to
discuss the details.
rgds
jan I.
>
> After discussing the features, we can see what technologies apply for. In
> advance, AJAX+REST is good for me.
>
> franz
>
>
>
[dfwebserver] API
Posted by Franz de Copenhague <fr...@outlook.com>.
I am thinking about what server features are required by the editor.
1. Upload a document
2. Get the HTML abstract of the document
3. Push the edited HTML representation in the document
4. Upload new images and other embbed objects in the edited HTML
5. Download the document
After discussing the features, we can see what technologies apply for. In advance, AJAX+REST is good for me.
franz
RE: Prototype web app, and Editor API
Posted by Franz de Copenhague <fr...@outlook.com>.
>>
>> Good to know, I am starting to understand the Apache ropes ;)
>>
>
> Heh, feel free to ask not everything is as bad or easy as it seems.
>
> If you want to know who we are:
> http://people.apache.org/committers-by-project.html#corinthia
>
> If you like to know a little about the roles apache uses and how we work
> (but when reading remember we nearly never pull out the roles, we try to
> solve everything by consensus):
> http://community.apache.org/
>
> But most importantly, Apache is not made to be a rope around your neck, but
> a rope you can climb and make 1+1=3. Like the rest of us you use your
> precious spare time for this, so it is important to have fun !
>
> Rgds
> jan I.
>
>
>
>>
x
With the expression Apache ropes, I mean to understand how something is done :)
franz
Re: Prototype web app, and Editor API
Posted by jan i <ja...@apache.org>.
On 12 March 2015 at 16:40, Franz de Copenhague <
franzdecopenhague@outlook.com> wrote:
> >>> Also, there is a lot of JS frameworks and libraries that could make us
> >> easier the front end development. And it is good to know how to deal
> with
> >> the Apache policy using third-party frameworks.
> >>
> > We have to be very careful here. One thing is to download something to
> > make a proof of concept it is quite different if we want to integrate it
> in
> > our code.
> >
> > In our repo itself we can only have ALv2 based code. We do have an option
> > to include libraries with support functions as category B code, but for
> > example we cannot include a whole editor.
> >
> > When we include libraries as category B, we only distribute them as
> > binaries (I am aware no such thing exist for JS, but the principle is
> > binary). We can only make really minor adaptations to the original code,
> > and no way develop on it.
> >
> > Category B code can be a number of licenses, like LGPL and MPL. We cannot
> > however use e.g. GPL or BSD, the reason is that they limit downstream
> > projects from e.g. making a derivative and sell it...something we at ASF
> > really like when it happens.
> >
> > Another item is, I am not sure why we would need an extensive JS
> framework,
> > we do have quite many lines of JS code in our own repo. I would much more
> > like us to develop the remaining parts of the editor, based on good ideas
> > from the others, so that the whole code was Corinthia code.
> >
> > Django is not something we can use to bind client and server, due to the
> > license. I am the admin of a couple of servers in infra, and Django is
> not
> > the easiest or most stable framework to maintain. We should aim at a
> > connection between client and server, that do not rely on extensions of
> the
> > http server.
> >
> > But all that said, it still look good.
> >
> > rgds
> > jan I.
> >
>
> Good to know, I am starting to understand the Apache ropes ;)
>
Heh, feel free to ask not everything is as bad or easy as it seems.
If you want to know who we are:
http://people.apache.org/committers-by-project.html#corinthia
If you like to know a little about the roles apache uses and how we work
(but when reading remember we nearly never pull out the roles, we try to
solve everything by consensus):
http://community.apache.org/
But most importantly, Apache is not made to be a rope around your neck, but
a rope you can climb and make 1+1=3. Like the rest of us you use your
precious spare time for this, so it is important to have fun !
Rgds
jan I.
>
> franz
RE: Prototype web app, and Editor API
Posted by Franz de Copenhague <fr...@outlook.com>.
>>> Also, there is a lot of JS frameworks and libraries that could make us
>> easier the front end development. And it is good to know how to deal with
>> the Apache policy using third-party frameworks.
>>
> We have to be very careful here. One thing is to download something to
> make a proof of concept it is quite different if we want to integrate it in
> our code.
>
> In our repo itself we can only have ALv2 based code. We do have an option
> to include libraries with support functions as category B code, but for
> example we cannot include a whole editor.
>
> When we include libraries as category B, we only distribute them as
> binaries (I am aware no such thing exist for JS, but the principle is
> binary). We can only make really minor adaptations to the original code,
> and no way develop on it.
>
> Category B code can be a number of licenses, like LGPL and MPL. We cannot
> however use e.g. GPL or BSD, the reason is that they limit downstream
> projects from e.g. making a derivative and sell it...something we at ASF
> really like when it happens.
>
> Another item is, I am not sure why we would need an extensive JS framework,
> we do have quite many lines of JS code in our own repo. I would much more
> like us to develop the remaining parts of the editor, based on good ideas
> from the others, so that the whole code was Corinthia code.
>
> Django is not something we can use to bind client and server, due to the
> license. I am the admin of a couple of servers in infra, and Django is not
> the easiest or most stable framework to maintain. We should aim at a
> connection between client and server, that do not rely on extensions of the
> http server.
>
> But all that said, it still look good.
>
> rgds
> jan I.
>
Good to know, I am starting to understand the Apache ropes ;)
franz
Re: Prototype web app, and Editor API
Posted by Peter Kelly <pm...@apache.org>.
> On 12 Mar 2015, at 10:25 pm, jan i <ja...@apache.org> wrote:
>
> Another item is, I am not sure why we would need an extensive JS framework,
> we do have quite many lines of JS code in our own repo. I would much more
> like us to develop the remaining parts of the editor, based on good ideas
> from the others, so that the whole code was Corinthia code.
IMHO we don’t need to use any third-party frameworks or libraries in the editor implementation code itself (i.e. everything in Editor/src/*.js); there’s been numerous instances where I’ve written my own implementation of something, so I can have full control over it in terms of design and also licensing. For example there is the Range class, which does similar things to the Rangy library (https://code.google.com/p/rangy/) [1]. As a general rule I try to stay away from frameworks because I find they complicate things, but in some cases they can make certain things like UIs easier.
It’s only for the UI code that I suggest we might consider using a 3rd-party framework - stuff like bootstrap, jQuery etc. Personally I’m quite happy to work without a 3rd-party framework (I know CSS/JS very intimately, but have almost no knowledge of how e.g. jQuery works). But if others who will be building the UI prefer a framework, then as long as licensing issues don’t cause problems I think it’s worth considering; it seems to be the norm for most web apps these days.
[1] Oops, google code shut down today. Here’s a version on GitHub: https://github.com/timdown/rangy
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Prototype web app, and Editor API
Posted by jan i <ja...@apache.org>.
On 12 March 2015 at 18:18, Dennis E. Hamilton <de...@acm.org>
wrote:
> Minor correction.
>
> The BSD License is not Category X. The commonly-used BSD license is a
> permissive license, just like the MIT license.
>
> However, LGPL *is* Category X, not Category B.
>
> The classifications and nuances are explained at <
> http://apache.org/legal/resolved.html>.
>
Thanks for the correction. I took it off my head, whenever we add code I
always check the latest legal.
rgds
jan i.
>
>
> -- Dennis E. Hamilton
> orcmid@apache.org
> dennis.hamilton@acm.org +1-206-779-9430
> https://keybase.io/orcmid PGP F96E 89FF D456 628A
> X.509 certs used and requested for signed e-mail
>
>
>
> -----Original Message-----
> From: jan i [mailto:jani@apache.org]
> Sent: Thursday, March 12, 2015 08:25
> To: dev@corinthia.incubator.apache.org
> Subject: Re: Prototype web app, and Editor API
>
> [ ... ]
>
> Category B code can be a number of licenses, like LGPL and MPL. We cannot
> however use e.g. GPL or BSD, the reason is that they limit downstream
> projects from e.g. making a derivative and sell it...something we at ASF
> really like when it happens.
>
> [ ... ]
>
>
RE: Prototype web app, and Editor API
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Minor correction.
The BSD License is not Category X. The commonly-used BSD license is a permissive license, just like the MIT license.
However, LGPL *is* Category X, not Category B.
The classifications and nuances are explained at <http://apache.org/legal/resolved.html>.
-- Dennis E. Hamilton
orcmid@apache.org
dennis.hamilton@acm.org +1-206-779-9430
https://keybase.io/orcmid PGP F96E 89FF D456 628A
X.509 certs used and requested for signed e-mail
-----Original Message-----
From: jan i [mailto:jani@apache.org]
Sent: Thursday, March 12, 2015 08:25
To: dev@corinthia.incubator.apache.org
Subject: Re: Prototype web app, and Editor API
[ ... ]
Category B code can be a number of licenses, like LGPL and MPL. We cannot
however use e.g. GPL or BSD, the reason is that they limit downstream
projects from e.g. making a derivative and sell it...something we at ASF
really like when it happens.
[ ... ]
Re: Prototype web app, and Editor API
Posted by jan i <ja...@apache.org>.
On 12 March 2015 at 16:05, Franz de Copenhague <
franzdecopenhague@outlook.com> wrote:
>
>
> ----------------------------------------
> > From: franzdecopenhague@outlook.com
> > To: dev@corinthia.incubator.apache.org
> > Subject: RE: Prototype web app, and Editor API
> > Date: Thu, 12 Mar 2015 14:26:56 +0000
> >
> >
> >
> >> From: pmkelly@apache.org
> >> Subject: Re: Prototype web app, and Editor API
> >> Date: Thu, 12 Mar 2015 18:15:30 +0700
> >> To: dev@corinthia.incubator.apache.org
> >>
> >>> On 12 Mar 2015, at 1:26 am, Franz de Copenhague <
> franzdecopenhague@outlook.com> wrote:
> >>>
> >>> I just built an django example to prototype the server-side. It uses
> the CKEditor but we can replace it by DocFormats web editor
> >>>
> http://django-ckeditor-franzdecopenhague.c9.io/admin/demo_application/examplemodel/2/
> >>> username/password: admin/admin
> >>> It is running in a developer python server, let me know if you cannot
> see the link.
> >>> JD
> >>
> >> This looks fantastic.
> >>
> >> Now that I’ve committed the proof of concept editor I’ve written to the
> repository (which has a very limited UI compared to what you’ve shown),
> would you like to have a go at this?
> >>
> >> Actually, is the UI there from CKEditor, or your own? The former is not
> Apache licensed which might be problematic. We’ll need to figure out what
> our/Apache’s policy is for using third-party frameworks in web apps.
> There’s a lot of good ones out there and it would be nice to be able to
> re-use them if licensing conditions allows.
> >>
> >> At any rate, I think a topic we should begin discussing is UI design.
> There are existing word processing/writing tools to draw inspiration from.
> Lets hear everyone’s ideas.
> >>
> >> —
> >> Dr Peter M. Kelly
> >>
> >
> > ----------------------------------------
> >
> > I am just running the demo application of django-ckeditor and all the UI
> functionality is out of the box. I did nothing.
> >
> > About the license, at the end of django-ckeditor Python Package Index
> says OSI Approved :: BSD License
> > https://pypi.python.org/pypi/django-ckeditor#downloads
> >
> > The JS CKEditor text editor says either GPL, LGPL or MPL
> > http://ckeditor.com/about/license
> >
> > Also, there is a lot of JS frameworks and libraries that could make us
> easier the front end development. And it is good to know how to deal with
> the Apache policy using third-party frameworks.
>
We have to be very careful here. One thing is to download something to
make a proof of concept it is quite different if we want to integrate it in
our code.
In our repo itself we can only have ALv2 based code. We do have an option
to include libraries with support functions as category B code, but for
example we cannot include a whole editor.
When we include libraries as category B, we only distribute them as
binaries (I am aware no such thing exist for JS, but the principle is
binary). We can only make really minor adaptations to the original code,
and no way develop on it.
Category B code can be a number of licenses, like LGPL and MPL. We cannot
however use e.g. GPL or BSD, the reason is that they limit downstream
projects from e.g. making a derivative and sell it...something we at ASF
really like when it happens.
Another item is, I am not sure why we would need an extensive JS framework,
we do have quite many lines of JS code in our own repo. I would much more
like us to develop the remaining parts of the editor, based on good ideas
from the others, so that the whole code was Corinthia code.
Django is not something we can use to bind client and server, due to the
license. I am the admin of a couple of servers in infra, and Django is not
the easiest or most stable framework to maintain. We should aim at a
connection between client and server, that do not rely on extensions of the
http server.
But all that said, it still look good.
rgds
jan I.
>
> > Regarding to the UI, I think is better start discussing about features.
> >
> > Franz
>
> I have downloaded the CKEditor sdk and you can see in the below link all
> the UI samples
> They have a lot of things to think about ...
>
> https://corinthia-franzdecopenhague.c9.io/ckeditor_sdk/index.html
>
> Franz
>
>
RE: Prototype web app, and Editor API
Posted by Franz de Copenhague <fr...@outlook.com>.
----------------------------------------
> From: franzdecopenhague@outlook.com
> To: dev@corinthia.incubator.apache.org
> Subject: RE: Prototype web app, and Editor API
> Date: Thu, 12 Mar 2015 14:26:56 +0000
>
>
>
>> From: pmkelly@apache.org
>> Subject: Re: Prototype web app, and Editor API
>> Date: Thu, 12 Mar 2015 18:15:30 +0700
>> To: dev@corinthia.incubator.apache.org
>>
>>> On 12 Mar 2015, at 1:26 am, Franz de Copenhague <fr...@outlook.com> wrote:
>>>
>>> I just built an django example to prototype the server-side. It uses the CKEditor but we can replace it by DocFormats web editor
>>> http://django-ckeditor-franzdecopenhague.c9.io/admin/demo_application/examplemodel/2/
>>> username/password: admin/admin
>>> It is running in a developer python server, let me know if you cannot see the link.
>>> JD
>>
>> This looks fantastic.
>>
>> Now that I’ve committed the proof of concept editor I’ve written to the repository (which has a very limited UI compared to what you’ve shown), would you like to have a go at this?
>>
>> Actually, is the UI there from CKEditor, or your own? The former is not Apache licensed which might be problematic. We’ll need to figure out what our/Apache’s policy is for using third-party frameworks in web apps. There’s a lot of good ones out there and it would be nice to be able to re-use them if licensing conditions allows.
>>
>> At any rate, I think a topic we should begin discussing is UI design. There are existing word processing/writing tools to draw inspiration from. Lets hear everyone’s ideas.
>>
>> —
>> Dr Peter M. Kelly
>>
>
> ----------------------------------------
>
> I am just running the demo application of django-ckeditor and all the UI functionality is out of the box. I did nothing.
>
> About the license, at the end of django-ckeditor Python Package Index says OSI Approved :: BSD License
> https://pypi.python.org/pypi/django-ckeditor#downloads
>
> The JS CKEditor text editor says either GPL, LGPL or MPL
> http://ckeditor.com/about/license
>
> Also, there is a lot of JS frameworks and libraries that could make us easier the front end development. And it is good to know how to deal with the Apache policy using third-party frameworks.
>
> Regarding to the UI, I think is better start discussing about features.
>
> Franz
I have downloaded the CKEditor sdk and you can see in the below link all the UI samples
They have a lot of things to think about ...
https://corinthia-franzdecopenhague.c9.io/ckeditor_sdk/index.html
Franz
RE: Prototype web app, and Editor API
Posted by Franz de Copenhague <fr...@outlook.com>.
> From: pmkelly@apache.org
> Subject: Re: Prototype web app, and Editor API
> Date: Thu, 12 Mar 2015 18:15:30 +0700
> To: dev@corinthia.incubator.apache.org
>
>> On 12 Mar 2015, at 1:26 am, Franz de Copenhague <fr...@outlook.com> wrote:
>>
>> I just built an django example to prototype the server-side. It uses the CKEditor but we can replace it by DocFormats web editor
>> http://django-ckeditor-franzdecopenhague.c9.io/admin/demo_application/examplemodel/2/
>> username/password: admin/admin
>> It is running in a developer python server, let me know if you cannot see the link.
>> JD
>
> This looks fantastic.
>
> Now that I’ve committed the proof of concept editor I’ve written to the repository (which has a very limited UI compared to what you’ve shown), would you like to have a go at this?
>
> Actually, is the UI there from CKEditor, or your own? The former is not Apache licensed which might be problematic. We’ll need to figure out what our/Apache’s policy is for using third-party frameworks in web apps. There’s a lot of good ones out there and it would be nice to be able to re-use them if licensing conditions allows.
>
> At any rate, I think a topic we should begin discussing is UI design. There are existing word processing/writing tools to draw inspiration from. Lets hear everyone’s ideas.
>
> —
> Dr Peter M. Kelly
>
----------------------------------------
I am just running the demo application of django-ckeditor and all the UI functionality is out of the box. I did nothing.
About the license, at the end of django-ckeditor Python Package Index says OSI Approved :: BSD License
https://pypi.python.org/pypi/django-ckeditor#downloads
The JS CKEditor text editor says either GPL, LGPL or MPL
http://ckeditor.com/about/license
Also, there is a lot of JS frameworks and libraries that could make us easier the front end development. And it is good to know how to deal with the Apache policy using third-party frameworks.
Regarding to the UI, I think is better start discussing about features.
Franz
Re: Prototype web app, and Editor API
Posted by Peter Kelly <pm...@apache.org>.
> On 12 Mar 2015, at 1:26 am, Franz de Copenhague <fr...@outlook.com> wrote:
>
> I just built an django example to prototype the server-side. It uses the CKEditor but we can replace it by DocFormats web editor
> http://django-ckeditor-franzdecopenhague.c9.io/admin/demo_application/examplemodel/2/
> username/password: admin/admin
> It is running in a developer python server, let me know if you cannot see the link.
> JD
This looks fantastic.
Now that I’ve committed the proof of concept editor I’ve written to the repository (which has a very limited UI compared to what you’ve shown), would you like to have a go at this?
Actually, is the UI there from CKEditor, or your own? The former is not Apache licensed which might be problematic. We’ll need to figure out what our/Apache’s policy is for using third-party frameworks in web apps. There’s a lot of good ones out there and it would be nice to be able to re-use them if licensing conditions allows.
At any rate, I think a topic we should begin discussing is UI design. There are existing word processing/writing tools to draw inspiration from. Lets hear everyone’s ideas.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: Prototype web app, and Editor API
Posted by jan i <ja...@apache.org>.
On 12 March 2015 at 06:42, Franz de Copenhague <
franzdecopenhague@outlook.com> wrote:
> > > My fault with HTML email
> > >
> > > try:
> > >
> > >
> > >
> http://django-ckeditor-franzdecopenhague.c9.io/admin/demo_application/examplemodel/2/
>
> > >
> >
> > A short run and go test worked for me...will look more carefully later.
> >
> > rgds
> > jan i.
> >
>
> I have created my first Python binding patch http://bit.ly/19dpO54
> Please, let me know how to procedure and any feedback is welcome.
>
> So far, there are only 2 functions in the Python API.
>
> import dfutil
> Import dfconvert
>
> dfutil.normalize("other.html")
> dfconvert.get("input.docx", "output.html")
>
> Thanks for the patch, I will take a closer look later and add it to master
branch.
I assume next step is to have the client and the server talk together, so
we can get the other calls implemented. We should use a standard method
like Ajax to do this, but lets us hear some suggestions.
rgds
jan i.
> jd
>
Re: [dfwebserver] Python binding
Posted by Peter Kelly <pm...@apache.org>.
> On 17 Mar 2015, at 6:52 pm, Franz de Copenhague <fr...@outlook.com> wrote:
>
> Jan, is there any C consumer for the JS functions that you point out above?
>
> Peter,
>
> Jan mentions this link https://cwiki.apache.org/confluence/display/Corinthia/API+reference but I am seeing a lot of functions required by the front-end aka Editor Library. Would you split up in 2 list for front-end and back-end? Also, will be very helpful to know what is the corresponding C API for each back-end functionality.
Unfortunately the way in which these functions can be called depends on the web browser engine/webview API in use. For example the way that it is done in iOS/OSX using Apple’s suppled UIWebView/WebView classes is different to how it will be done for Qt bindings. Calling these functions from a C program (or C++ or Objective C) depends on the API exposed by the web browser engine, which can differ between applications.
DocFormats is logically separate from the editing code, in that it can be used in and of itself - in particular, it is useful to have on the server side for various conversion processes a website might need, and also for supporting conversion to be used by web-based apps built on the library (which I’ve got an early proof of concept of in the repo, but without the server component). In the latter case, the editing would be on the client’s browser.
Regarding the API of DocFormats, as Jan mentioned, this really hasn’t been decided on properly yet, aside from the three main conversion functions. The one other set of APIs, which could arguably considered public (UX Write uses them, and the Qt app will need to as well) are those for representing CSS stylesheets. So as a next step towards python bindings, I would suggest looking at the CSSSheet, CSSStyle, and CSSProperties classes.
The next thing after that is the DOM API. I’m undecided as to how that would be best exposed in Python. We could write bindings as-is, although Python already has the xml.dom module [1] which, if my understanding is correct, permits multiple implementations. So it may be worth creating bindings to conform to that, so that people can re-use existing DOM-manipulating python code based on the xml.dom APIs in conjunction with DocFormats.
[1] https://docs.python.org/3/library/xml.dom.html
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: [dfwebserver] Python binding
Posted by jan i <ja...@apache.org>.
On 17 March 2015 at 12:52, Franz de Copenhague <
franzdecopenhague@outlook.com> wrote:
>
>
> ----------------------------------------
> > Date: Tue, 17 Mar 2015 12:15:34 +0100
> > Subject: Re: [dfwebserver] Python binding
> > From: jani@apache.org
> > To: dev@corinthia.incubator.apache.org
> >
> > On 17 March 2015 at 12:05, Franz de Copenhague <
> > franzdecopenhague@outlook.com> wrote:
> >
> >>
> >>> I think my technical comment might have got lost in translation :-)
> >>>
> >>> Could you please consider naming your bindings different, I actually
> >>> thought you had copied the dfconvert code
> >>
> >> I think that using a similar name to the C API which is been binding to
> >> python makes sense and it is how other bindings are done. So, a
> developer
> >> whom knows DocFormat C API would understand the python API at first
> place.
> >>
> >>> I would suggest (but it is your choice) to put all bindings in 1 source
> >>> file and name it e.g. docFormatPython.c
> >>
> >> The bindind is following the consumers C API pattern with 2 main.c files
> >> for dfconvert and dfutil that generates 2 executables dfconvert and
> dfutil.
> >> For me, makes sense your suggestion if you have plans to refactory the
> >> DocFormat C API and have only one main.c with dfconvert and dfutil
> features
> >> all together.
> >>
> >
> > Please be aware dfconvert and dfutil are consumers the USE docFormat.lib
> > they do not represent the docformats API.
> >
> > if you look inside dfconvert/dfutil they call functions inside docFormats
> > (the library) that is part of the API.
> >
> > I think peter gave you a list of all the JS functions we have that calls
> > back info the library (it is some 40+ calls)
> >
> > So seen from a release perspective our aim is to have
> >
> > docFormats library with a C-api
> > dfconvert executable as a consumer of docFormats
> > dftest executable as a consumer of docFormats
> > dfWebServer executable as a consumer with python bindings fo docFormats
> >
> > So you can dfconvert, dftest and dfWebserver is parallel (dfutil is more
> or
> > less on its way out).
> >
> > I hope that explains why I suggested a name change.
> >
> > rgds
> > jan I.
> >
>
> Jan, is there any C consumer for the JS functions that you point out above?
>
No not currently the consumer "corinthia" (desktop editor) will use them
all.
>
> Peter,
>
> Jan mentions this link
> https://cwiki.apache.org/confluence/display/Corinthia/API+reference but I
> am seeing a lot of functions required by the front-end aka Editor Library.
> Would you split up in 2 list for front-end and back-end? Also, will be very
> helpful to know what is the corresponding C API for each back-end
> functionality.
>
We need them all, the frontend calls the backend which call the C API.
Sadly enough docformat library does not yet have a formal C Api, but we
call functions deep within.
I am working on the desktop editor (right now stuck in some 64bit issues),
and as I work through it, I will have the functions calling the
corresponding docformats functions.
I did not expect you to implement all these bindings, since they do not
exist, but merely used it to explain why I feel you use wrong names for
your current bindings.
Let us first get that up and running you have, and hope that I in the
meantime can provide a consumer that shows all the needed calls.
rgds
jan I.
>
> franz
>
>
>
RE: [dfwebserver] Python binding
Posted by Franz de Copenhague <fr...@outlook.com>.
----------------------------------------
> Date: Tue, 17 Mar 2015 12:15:34 +0100
> Subject: Re: [dfwebserver] Python binding
> From: jani@apache.org
> To: dev@corinthia.incubator.apache.org
>
> On 17 March 2015 at 12:05, Franz de Copenhague <
> franzdecopenhague@outlook.com> wrote:
>
>>
>>> I think my technical comment might have got lost in translation :-)
>>>
>>> Could you please consider naming your bindings different, I actually
>>> thought you had copied the dfconvert code
>>
>> I think that using a similar name to the C API which is been binding to
>> python makes sense and it is how other bindings are done. So, a developer
>> whom knows DocFormat C API would understand the python API at first place.
>>
>>> I would suggest (but it is your choice) to put all bindings in 1 source
>>> file and name it e.g. docFormatPython.c
>>
>> The bindind is following the consumers C API pattern with 2 main.c files
>> for dfconvert and dfutil that generates 2 executables dfconvert and dfutil.
>> For me, makes sense your suggestion if you have plans to refactory the
>> DocFormat C API and have only one main.c with dfconvert and dfutil features
>> all together.
>>
>
> Please be aware dfconvert and dfutil are consumers the USE docFormat.lib
> they do not represent the docformats API.
>
> if you look inside dfconvert/dfutil they call functions inside docFormats
> (the library) that is part of the API.
>
> I think peter gave you a list of all the JS functions we have that calls
> back info the library (it is some 40+ calls)
>
> So seen from a release perspective our aim is to have
>
> docFormats library with a C-api
> dfconvert executable as a consumer of docFormats
> dftest executable as a consumer of docFormats
> dfWebServer executable as a consumer with python bindings fo docFormats
>
> So you can dfconvert, dftest and dfWebserver is parallel (dfutil is more or
> less on its way out).
>
> I hope that explains why I suggested a name change.
>
> rgds
> jan I.
>
Jan, is there any C consumer for the JS functions that you point out above?
Peter,
Jan mentions this link https://cwiki.apache.org/confluence/display/Corinthia/API+reference but I am seeing a lot of functions required by the front-end aka Editor Library. Would you split up in 2 list for front-end and back-end? Also, will be very helpful to know what is the corresponding C API for each back-end functionality.
franz
Re: [dfwebserver] Python binding
Posted by jan i <ja...@apache.org>.
On 17 March 2015 at 12:05, Franz de Copenhague <
franzdecopenhague@outlook.com> wrote:
>
> > I think my technical comment might have got lost in translation :-)
> >
> > Could you please consider naming your bindings different, I actually
> > thought you had copied the dfconvert code
>
> I think that using a similar name to the C API which is been binding to
> python makes sense and it is how other bindings are done. So, a developer
> whom knows DocFormat C API would understand the python API at first place.
>
> > I would suggest (but it is your choice) to put all bindings in 1 source
> > file and name it e.g. docFormatPython.c
>
> The bindind is following the consumers C API pattern with 2 main.c files
> for dfconvert and dfutil that generates 2 executables dfconvert and dfutil.
> For me, makes sense your suggestion if you have plans to refactory the
> DocFormat C API and have only one main.c with dfconvert and dfutil features
> all together.
>
Please be aware dfconvert and dfutil are consumers the USE docFormat.lib
they do not represent the docformats API.
if you look inside dfconvert/dfutil they call functions inside docFormats
(the library) that is part of the API.
I think peter gave you a list of all the JS functions we have that calls
back info the library (it is some 40+ calls)
So seen from a release perspective our aim is to have
docFormats library with a C-api
dfconvert executable as a consumer of docFormats
dftest executable as a consumer of docFormats
dfWebServer executable as a consumer with python bindings fo docFormats
So you can dfconvert, dftest and dfWebserver is parallel (dfutil is more or
less on its way out).
I hope that explains why I suggested a name change.
rgds
jan I.
>
> It is pretty strait forward to do in a command shell:
>
> dfconvert get input.docx abstract.html
>
> And do the same in python or javascript
>
> import dfconvert
> dfconvert.get( "input.docx", "abstract.html")
>
> var dfconvert = require("dfconvert");
> dfconvert.get("input.docx", "abstract.html")
>
> franz
>
>
RE: [dfwebserver] Python binding
Posted by Franz de Copenhague <fr...@outlook.com>.
> I think my technical comment might have got lost in translation :-)
>
> Could you please consider naming your bindings different, I actually
> thought you had copied the dfconvert code
I think that using a similar name to the C API which is been binding to python makes sense and it is how other bindings are done. So, a developer whom knows DocFormat C API would understand the python API at first place.
> I would suggest (but it is your choice) to put all bindings in 1 source
> file and name it e.g. docFormatPython.c
The bindind is following the consumers C API pattern with 2 main.c files for dfconvert and dfutil that generates 2 executables dfconvert and dfutil. For me, makes sense your suggestion if you have plans to refactory the DocFormat C API and have only one main.c with dfconvert and dfutil features all together.
It is pretty strait forward to do in a command shell:
dfconvert get input.docx abstract.html
And do the same in python or javascript
import dfconvert
dfconvert.get( "input.docx", "abstract.html")
var dfconvert = require("dfconvert");
dfconvert.get("input.docx", "abstract.html")
franz
Re: [dfwebserver] Python binding
Posted by jan i <ja...@apache.org>.
On 16 March 2015 at 13:58, Franz de Copenhague <
franzdecopenhague@outlook.com> wrote:
> I have added the APIs dfconvert.put dfconvert.create to the python
> binding. In this URL you can download the patch http://bit.ly/1x80xUr
>
I think my technical comment might have got lost in translation :-)
Could you please consider naming your bindings different, I actually
thought you had copied the dfconvert code
I would suggest (but it is your choice) to put all bindings in 1 source
file and name it e.g. docFormatPython.c
rgds
jan I.
>
> franz
RE: [dfwebserver] Python binding
Posted by Franz de Copenhague <fr...@outlook.com>.
----------------------------------------
> From: dennis.hamilton@acm.org
> To: dev@corinthia.incubator.apache.org
> Subject: RE: [dfwebserver] Python binding
> Date: Mon, 16 Mar 2015 08:45:36 -0700
>
> Or create an issue (a Task or a Feature) and attach the patch to it? That is a common way to submit patches. It provides an easier-to-access history of the patch development.
>
> - Dennis
>
Sounds good. I will do next time.
franz
RE: [dfwebserver] Python binding
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Or create an issue (a Task or a Feature) and attach the patch to it? That is a common way to submit patches. It provides an easier-to-access history of the patch development.
- Dennis
-----Original Message-----
From: Peter Kelly [mailto:pmkelly@apache.org]
Sent: Monday, March 16, 2015 08:22
To: dev@corinthia.incubator.apache.org
Subject: Re: [dfwebserver] Python binding
Hi Franz,
I tried to access the URL but got the following error message:
Client Closed Request
499 - vfs VFS connection does not exist
Try attaching the patch directly to your mail; and in the event it isn’t accepted by the mailing list try sending it directly to me.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> On 16 Mar 2015, at 7:58 pm, Franz de Copenhague <fr...@outlook.com> wrote:
>
> I have added the APIs dfconvert.put dfconvert.create to the python binding. In this URL you can download the patch http://bit.ly/1x80xUr
>
> franz
Re: [dfwebserver] Python binding
Posted by Peter Kelly <pm...@apache.org>.
Thans Franz, that’s excellent.
And Dennis: I was probably a bit strong in my comments… sorry about that. I just want to make sure we’re valuing people at least as much as process.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> On 17 Mar 2015, at 8:23 am, Franz de Copenhague <fr...@outlook.com> wrote:
>
> I have already sent the signed PDF to secretary@apache.org
>
> Thanks,
> franz
>
>> -----Original Message-----
>> From: Peter Kelly [mailto:pmkelly@apache.org]
>> Sent: Monday, March 16, 2015 9:09 PM
>> To: dev@corinthia.incubator.apache.org
>> Subject: Re: [dfwebserver] Python binding
>>
>> Dennis: I understand your concerns about ICLA etc and appreciate you raising
>> this important issue. However I feel that the way in which you are
>> approaching it is being actively hostile towards a new contributor; we want to
>> attract people and we must express that their contributions are valued, and
>> work towards doing so. The two patches I’ve committed from Franz so far
>> have been small enough that according to my understanding they fall within
>> the same categorisation normally applied to patches - if a larger amount of
>> code were in question, then I would have acted differently.
>>
>> I should mention that there were multiple issues that came up during my
>> journey into Apache and at one point I actually said I didn’t want any part of it
>> and would take the project to Github or somewhere else. I only stuck with it
>> because of the encouragement of certain people. Policies and licensing are
>> certainly very important, but so are people - both are necessary
>> requirements for a project to succeed.
>>
>> That doesn’t mean of course that we can skip on any rules - like any project
>> we must make sure we’re fulfilling the necessary legal requirements for
>> accepting contributions. So:
>>
>> Franz: Welcome. As you’ve seen, one of the things that we’re supposed to
>> do for non-trivial contributions is for Apache to have an ICLA
>> (http://www.apache.org/licenses/icla.txt) on file from contributors. I can see
>> you’re doing some good work and anticipate more code from you. Would
>> you be willing to fill out an ICLA so that we can ensure we are meeting the
>> necessary legal/policy requirements in accepting your code? (this is a pre-
>> requisite for all people wishing to become committers to Apache projects).
>>
>> —
>> Dr Peter M. Kelly
>> pmkelly@apache.org
>>
>> PGP key: http://www.kellypmk.net/pgp-key
>> <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F BFA0
>> 5E46 2523 BAA1 44AE 2966)
>>
>>> On 16 Mar 2015, at 11:44 pm, jan i <ja...@apache.org> wrote:
>>>
>>> On 16 March 2015 at 17:14, Dennis E. Hamilton
>>> <de...@acm.org>
>>> wrote:
>>>
>>>> It occurred to me that these are substantial contributions.
>>>>
>>> I have to disagree with you here. You forget the big part is standard
>>> code and not something Franz has made. He has basically made the
>>> python bindings and that is not a substantial contribution.
>>>
>>>>
>>>> It is important for Franz to provide a Contributor License Agreement.
>>>> See <http://www.apache.org/licenses/#clas>.
>>>>
>>> No it is not. We do not demand that Franz sign a ICLA. But if Franz
>>> would like to sign one, it would be beneficial to us all.
>>>
>>>
>>>>
>>>> Franz, if you have any questions about this and submitting the
>>>> agreement, you can ask on this list. If you want to discuss this
>>>> privately, you can send your comments and questions to
>>>> private@corinthia.incubator.apache.org
>>>>
>>>>
>>> Dennis@ please do not put this as a demand, when we have another
>>> thread where we said it is not needed....we as PMC has not even discussed
>> it.
>>>
>>> Franz@ If you would like to sign an ICLA as a first step of comming
>>> closer to the project, please follow what Dennis writes. BUT your work
>>> is apriciated with our without an ICLA.
>>>
>>> rgds
>>> jan I.
>>>
>>>>
>>>> - Dennis
>>>>
>>>> -----Original Message-----
>>>> From: Peter Kelly [mailto:pmkelly@apache.org]
>>>> Sent: Monday, March 16, 2015 08:48
>>>> To: dev@corinthia.incubator.apache.org
>>>> Subject: Re: [dfwebserver] Python binding
>>>>
>>>>> On 16 Mar 2015, at 10:33 pm, Franz de Copenhague <
>>>> franzdecopenhague@outlook.com> wrote:
>>>>>
>>>>> Attached you have the path.
>>>>
>>>> Thanks Franz - received and committed. Looks like some good progress,
>>>> nice to see.
>>>>
>>>> —
>>>> Dr Peter M. Kelly
>>>> pmkelly@apache.org
>>>>
>>>> PGP key: http://www.kellypmk.net/pgp-key
>>>> <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F
>>>> BFA0 5E46 2523 BAA1 44AE 2966)
>>>>
>>>>
>>>>
>
RE: [dfwebserver] Python binding
Posted by Franz de Copenhague <fr...@outlook.com>.
I have already sent the signed PDF to secretary@apache.org
Thanks,
franz
> -----Original Message-----
> From: Peter Kelly [mailto:pmkelly@apache.org]
> Sent: Monday, March 16, 2015 9:09 PM
> To: dev@corinthia.incubator.apache.org
> Subject: Re: [dfwebserver] Python binding
>
> Dennis: I understand your concerns about ICLA etc and appreciate you raising
> this important issue. However I feel that the way in which you are
> approaching it is being actively hostile towards a new contributor; we want to
> attract people and we must express that their contributions are valued, and
> work towards doing so. The two patches I’ve committed from Franz so far
> have been small enough that according to my understanding they fall within
> the same categorisation normally applied to patches - if a larger amount of
> code were in question, then I would have acted differently.
>
> I should mention that there were multiple issues that came up during my
> journey into Apache and at one point I actually said I didn’t want any part of it
> and would take the project to Github or somewhere else. I only stuck with it
> because of the encouragement of certain people. Policies and licensing are
> certainly very important, but so are people - both are necessary
> requirements for a project to succeed.
>
> That doesn’t mean of course that we can skip on any rules - like any project
> we must make sure we’re fulfilling the necessary legal requirements for
> accepting contributions. So:
>
> Franz: Welcome. As you’ve seen, one of the things that we’re supposed to
> do for non-trivial contributions is for Apache to have an ICLA
> (http://www.apache.org/licenses/icla.txt) on file from contributors. I can see
> you’re doing some good work and anticipate more code from you. Would
> you be willing to fill out an ICLA so that we can ensure we are meeting the
> necessary legal/policy requirements in accepting your code? (this is a pre-
> requisite for all people wishing to become committers to Apache projects).
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key
> <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F BFA0
> 5E46 2523 BAA1 44AE 2966)
>
> > On 16 Mar 2015, at 11:44 pm, jan i <ja...@apache.org> wrote:
> >
> > On 16 March 2015 at 17:14, Dennis E. Hamilton
> > <de...@acm.org>
> > wrote:
> >
> >> It occurred to me that these are substantial contributions.
> >>
> > I have to disagree with you here. You forget the big part is standard
> > code and not something Franz has made. He has basically made the
> > python bindings and that is not a substantial contribution.
> >
> >>
> >> It is important for Franz to provide a Contributor License Agreement.
> >> See <http://www.apache.org/licenses/#clas>.
> >>
> > No it is not. We do not demand that Franz sign a ICLA. But if Franz
> > would like to sign one, it would be beneficial to us all.
> >
> >
> >>
> >> Franz, if you have any questions about this and submitting the
> >> agreement, you can ask on this list. If you want to discuss this
> >> privately, you can send your comments and questions to
> >> private@corinthia.incubator.apache.org
> >>
> >>
> > Dennis@ please do not put this as a demand, when we have another
> > thread where we said it is not needed....we as PMC has not even discussed
> it.
> >
> > Franz@ If you would like to sign an ICLA as a first step of comming
> > closer to the project, please follow what Dennis writes. BUT your work
> > is apriciated with our without an ICLA.
> >
> > rgds
> > jan I.
> >
> >>
> >> - Dennis
> >>
> >> -----Original Message-----
> >> From: Peter Kelly [mailto:pmkelly@apache.org]
> >> Sent: Monday, March 16, 2015 08:48
> >> To: dev@corinthia.incubator.apache.org
> >> Subject: Re: [dfwebserver] Python binding
> >>
> >>> On 16 Mar 2015, at 10:33 pm, Franz de Copenhague <
> >> franzdecopenhague@outlook.com> wrote:
> >>>
> >>> Attached you have the path.
> >>
> >> Thanks Franz - received and committed. Looks like some good progress,
> >> nice to see.
> >>
> >> —
> >> Dr Peter M. Kelly
> >> pmkelly@apache.org
> >>
> >> PGP key: http://www.kellypmk.net/pgp-key
> >> <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F
> >> BFA0 5E46 2523 BAA1 44AE 2966)
> >>
> >>
> >>
Re: [dfwebserver] Python binding
Posted by Peter Kelly <pm...@apache.org>.
Dennis: I understand your concerns about ICLA etc and appreciate you raising this important issue. However I feel that the way in which you are approaching it is being actively hostile towards a new contributor; we want to attract people and we must express that their contributions are valued, and work towards doing so. The two patches I’ve committed from Franz so far have been small enough that according to my understanding they fall within the same categorisation normally applied to patches - if a larger amount of code were in question, then I would have acted differently.
I should mention that there were multiple issues that came up during my journey into Apache and at one point I actually said I didn’t want any part of it and would take the project to Github or somewhere else. I only stuck with it because of the encouragement of certain people. Policies and licensing are certainly very important, but so are people - both are necessary requirements for a project to succeed.
That doesn’t mean of course that we can skip on any rules - like any project we must make sure we’re fulfilling the necessary legal requirements for accepting contributions. So:
Franz: Welcome. As you’ve seen, one of the things that we’re supposed to do for non-trivial contributions is for Apache to have an ICLA (http://www.apache.org/licenses/icla.txt) on file from contributors. I can see you’re doing some good work and anticipate more code from you. Would you be willing to fill out an ICLA so that we can ensure we are meeting the necessary legal/policy requirements in accepting your code? (this is a pre-requisite for all people wishing to become committers to Apache projects).
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> On 16 Mar 2015, at 11:44 pm, jan i <ja...@apache.org> wrote:
>
> On 16 March 2015 at 17:14, Dennis E. Hamilton <de...@acm.org>
> wrote:
>
>> It occurred to me that these are substantial contributions.
>>
> I have to disagree with you here. You forget the big part is standard code
> and not something Franz has made. He has basically made the python bindings
> and that is not a substantial contribution.
>
>>
>> It is important for Franz to provide a Contributor License Agreement. See
>> <http://www.apache.org/licenses/#clas>.
>>
> No it is not. We do not demand that Franz sign a ICLA. But if Franz would
> like to sign one, it would be beneficial to us all.
>
>
>>
>> Franz, if you have any questions about this and submitting the agreement,
>> you can ask on this list. If you want to discuss this privately, you can
>> send your comments and questions to private@corinthia.incubator.apache.org
>>
>>
> Dennis@ please do not put this as a demand, when we have another thread
> where we said it is not needed....we as PMC has not even discussed it.
>
> Franz@ If you would like to sign an ICLA as a first step of comming closer
> to the project, please follow what Dennis writes. BUT your work is
> apriciated with our without an ICLA.
>
> rgds
> jan I.
>
>>
>> - Dennis
>>
>> -----Original Message-----
>> From: Peter Kelly [mailto:pmkelly@apache.org]
>> Sent: Monday, March 16, 2015 08:48
>> To: dev@corinthia.incubator.apache.org
>> Subject: Re: [dfwebserver] Python binding
>>
>>> On 16 Mar 2015, at 10:33 pm, Franz de Copenhague <
>> franzdecopenhague@outlook.com> wrote:
>>>
>>> Attached you have the path.
>>
>> Thanks Franz - received and committed. Looks like some good progress, nice
>> to see.
>>
>> —
>> Dr Peter M. Kelly
>> pmkelly@apache.org
>>
>> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
>> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>>
>>
>>
Re: [dfwebserver] Python binding
Posted by jan i <ja...@apache.org>.
On 16 March 2015 at 17:14, Dennis E. Hamilton <de...@acm.org>
wrote:
> It occurred to me that these are substantial contributions.
>
I have to disagree with you here. You forget the big part is standard code
and not something Franz has made. He has basically made the python bindings
and that is not a substantial contribution.
>
> It is important for Franz to provide a Contributor License Agreement. See
> <http://www.apache.org/licenses/#clas>.
>
No it is not. We do not demand that Franz sign a ICLA. But if Franz would
like to sign one, it would be beneficial to us all.
>
> Franz, if you have any questions about this and submitting the agreement,
> you can ask on this list. If you want to discuss this privately, you can
> send your comments and questions to private@corinthia.incubator.apache.org
>
>
Dennis@ please do not put this as a demand, when we have another thread
where we said it is not needed....we as PMC has not even discussed it.
Franz@ If you would like to sign an ICLA as a first step of comming closer
to the project, please follow what Dennis writes. BUT your work is
apriciated with our without an ICLA.
rgds
jan I.
>
> - Dennis
>
> -----Original Message-----
> From: Peter Kelly [mailto:pmkelly@apache.org]
> Sent: Monday, March 16, 2015 08:48
> To: dev@corinthia.incubator.apache.org
> Subject: Re: [dfwebserver] Python binding
>
> > On 16 Mar 2015, at 10:33 pm, Franz de Copenhague <
> franzdecopenhague@outlook.com> wrote:
> >
> > Attached you have the path.
>
> Thanks Franz - received and committed. Looks like some good progress, nice
> to see.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
>
Re: [dfwebserver] Python binding
Posted by Peter Kelly <pm...@apache.org>.
> On 17 Mar 2015, at 10:33 pm, Franz de Copenhague <fr...@outlook.com> wrote:
>
> ----------------------------------------
>> From: pmkelly@apache.org
>> nodeJS bindings sound great BTW! Perhaps we can implement a server-side component in both Python as well as nodeJS - this way, it makes the library useful to a wider range of people who might consider using it for various purposes in their web apps or for other back-end processing tasks.
>>
>
> I see that you point out what was my intention creating dfwebserve: a server-side component
Ah yes - I realise that (poor choice of wording in my ail); I was just referencing the benefits of doing it in multiple languages :)
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
RE: [dfwebserver] Python binding
Posted by Franz de Copenhague <fr...@outlook.com>.
----------------------------------------
> From: pmkelly@apache.org
> nodeJS bindings sound great BTW! Perhaps we can implement a server-side component in both Python as well as nodeJS - this way, it makes the library useful to a wider range of people who might consider using it for various purposes in their web apps or for other back-end processing tasks.
>
I see that you point out what was my intention creating dfwebserve: a server-side component
franz
Re: [dfwebserver] Python binding
Posted by Peter Kelly <pm...@apache.org>.
> On 17 Mar 2015, at 12:27 am, Franz de Copenhague <fr...@outlook.com> wrote:
>
> The submitted code is just experimental code. And you are right, it doesn't honor the Apache headers.
>
> Also it only builds in Linux and a little refactory is required to do.
>
> I would like to submit python and nodeJS bindings in the future to try different approaches of web servers able to run DocFormats API.
nodeJS bindings sound great BTW! Perhaps we can implement a server-side component in both Python as well as nodeJS - this way, it makes the library useful to a wider range of people who might consider using it for various purposes in their web apps or for other back-end processing tasks.
I’m a big fan of both languages. I’ve been doing a lot of Python work lately in another job (using Flask as the web server) and have come to like it, but node is also nicely done (with the exception of callback hell, which can be avoided through promises and the like - nice to see the teaching of SICP [1] finally making it into the mainstream after 20 years ;)
[1] http://mitpress.mit.edu/sicp/
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: [dfwebserver] Python binding
Posted by jan i <ja...@apache.org>.
On 16 March 2015 at 18:27, Franz de Copenhague <
franzdecopenhague@outlook.com> wrote:
> The submitted code is just experimental code. And you are right, it
> doesn't honor the Apache headers.
I will post another mail in a minute trying to show the differences, and
what you should do, and what you should not do.
>
> Also it only builds in Linux and a little refactory is required to do.
>
yes that is what we agreed to.
>
> I would like to submit python and nodeJS bindings in the future to try
> different approaches of web servers able to run DocFormats API.
>
I see the bindings as something we will add to the product, once we have
some stability.
>
> Regarding to the ICLA, I already have signed it. Whom I can send it?
>
secretary@apache.org as a pdf.
2 questions:
1) Did you remember to write corinthia as project
2) Did you choose a apache id (that does not conflict, see
http://people.apache.org/committer-index.html )
Thanks for volunteering to submit the ICLA that will avoid some other
discussions.
rgds
jan i
>
> -franz
RE: [dfwebserver] Python binding
Posted by Franz de Copenhague <fr...@outlook.com>.
The submitted code is just experimental code. And you are right, it doesn't honor the Apache headers.
Also it only builds in Linux and a little refactory is required to do.
I would like to submit python and nodeJS bindings in the future to try different approaches of web servers able to run DocFormats API.
Regarding to the ICLA, I already have signed it. Whom I can send it?
-franz
Re: [dfwebserver] Python binding
Posted by jan i <ja...@apache.org>.
On 16 March 2015 at 17:26, Dennis E. Hamilton <de...@acm.org>
wrote:
> I notice that we are adding material that doesn't have the standard Apache
> Project license header.
>
to be honest I did not check the latest pything binding files, I assumed
peter controlled that when committing.
>
> I'm thinking we need to make a habit of putting the notice on new files.
>
For sure and I think we normally do. But we do not put our license to
standard code.
Please be aware that the whole webap is right now experimentel, and we need
to decide what we want (can) use of third party software, and once we have
that separate it from the rest.
I am (partly together with peter), the one that said lets go ahead with the
experiment, and integreate it a bit later. I am convinced the code we have
under web right now will not be released.
>
> Do we need an issue about repairing the contributions that don't have
> those?
>
If you refer to anything else than the new web directory, which are
experimental, then yes.
rgds
jan I.
>
> - Dennis
>
> -----Original Message-----
> From: Peter Kelly [mailto:pmkelly@apache.org]
> Sent: Monday, March 16, 2015 08:48
> To: dev@corinthia.incubator.apache.org
> Subject: Re: [dfwebserver] Python binding
>
> > On 16 Mar 2015, at 10:33 pm, Franz de Copenhague <
> franzdecopenhague@outlook.com> wrote:
> >
> > Attached you have the path.
>
> Thanks Franz - received and committed. Looks like some good progress, nice
> to see.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
>
RE: [dfwebserver] Python binding
Posted by Franz de Copenhague <fr...@outlook.com>.
----------------------------------------
> From: dennis.hamilton@acm.org
> To: dev@corinthia.incubator.apache.org
> Subject: RE: [dfwebserver] Python binding
> Date: Mon, 16 Mar 2015 09:26:25 -0700
>
> I notice that we are adding material that doesn't have the standard Apache Project license header.
>
> I'm thinking we need to make a habit of putting the notice on new files.
>
> Do we need an issue about repairing the contributions that don't have those?
>
> - Dennis
>
I will fix it in the next patch or submission.
franz
RE: [dfwebserver] Python binding
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I notice that we are adding material that doesn't have the standard Apache Project license header.
I'm thinking we need to make a habit of putting the notice on new files.
Do we need an issue about repairing the contributions that don't have those?
- Dennis
-----Original Message-----
From: Peter Kelly [mailto:pmkelly@apache.org]
Sent: Monday, March 16, 2015 08:48
To: dev@corinthia.incubator.apache.org
Subject: Re: [dfwebserver] Python binding
> On 16 Mar 2015, at 10:33 pm, Franz de Copenhague <fr...@outlook.com> wrote:
>
> Attached you have the path.
Thanks Franz - received and committed. Looks like some good progress, nice to see.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
RE: [dfwebserver] Python binding
Posted by "Dennis E. Hamilton" <de...@acm.org>.
It occurred to me that these are substantial contributions.
It is important for Franz to provide a Contributor License Agreement. See <http://www.apache.org/licenses/#clas>.
Franz, if you have any questions about this and submitting the agreement, you can ask on this list. If you want to discuss this privately, you can send your comments and questions to private@corinthia.incubator.apache.org
- Dennis
-----Original Message-----
From: Peter Kelly [mailto:pmkelly@apache.org]
Sent: Monday, March 16, 2015 08:48
To: dev@corinthia.incubator.apache.org
Subject: Re: [dfwebserver] Python binding
> On 16 Mar 2015, at 10:33 pm, Franz de Copenhague <fr...@outlook.com> wrote:
>
> Attached you have the path.
Thanks Franz - received and committed. Looks like some good progress, nice to see.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
Re: [dfwebserver] Python binding
Posted by Peter Kelly <pm...@apache.org>.
> On 16 Mar 2015, at 10:33 pm, Franz de Copenhague <fr...@outlook.com> wrote:
>
> Attached you have the path.
Thanks Franz - received and committed. Looks like some good progress, nice to see.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
RE: [dfwebserver] Python binding
Posted by Franz de Copenhague <fr...@outlook.com>.
Attached you have the path.
franz
----------------------------------------
> From: pmkelly@apache.org
> Subject: Re: [dfwebserver] Python binding
> Date: Mon, 16 Mar 2015 22:22:11 +0700
> To: dev@corinthia.incubator.apache.org
>
> Hi Franz,
>
> I tried to access the URL but got the following error message:
>
> Client Closed Request
> 499 - vfs VFS connection does not exist
>
> Try attaching the patch directly to your mail; and in the event it isn’t accepted by the mailing list try sending it directly to me.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>> On 16 Mar 2015, at 7:58 pm, Franz de Copenhague <fr...@outlook.com> wrote:
>>
>> I have added the APIs dfconvert.put dfconvert.create to the python binding. In this URL you can download the patch http://bit.ly/1x80xUr
>>
>> franz
>
Re: [dfwebserver] Python binding
Posted by Peter Kelly <pm...@apache.org>.
Hi Franz,
I tried to access the URL but got the following error message:
Client Closed Request
499 - vfs VFS connection does not exist
Try attaching the patch directly to your mail; and in the event it isn’t accepted by the mailing list try sending it directly to me.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> On 16 Mar 2015, at 7:58 pm, Franz de Copenhague <fr...@outlook.com> wrote:
>
> I have added the APIs dfconvert.put dfconvert.create to the python binding. In this URL you can download the patch http://bit.ly/1x80xUr
>
> franz
[dfwebserver] Python binding
Posted by Franz de Copenhague <fr...@outlook.com>.
I have added the APIs dfconvert.put dfconvert.create to the python binding. In this URL you can download the patch http://bit.ly/1x80xUr
franz
Re: Prototype web app, and Editor API
Posted by jan i <ja...@apache.org>.
On 14 March 2015 at 13:12, Franz de Copenhague <
franzdecopenhague@outlook.com> wrote:
> > -----Original Message-----
> > From: Peter Kelly [mailto:pmkelly@apache.org]
> > Sent: Friday, March 13, 2015 1:35 PM
> > To: dev@corinthia.incubator.apache.org
> > Subject: Re: Prototype web app, and Editor API
> >
> > Hi Franz, I’ve just committed your patch to the repository. I’m looking
> > forward to seeing more on the python bindings!
> >
>
> After pulling the latest change I couldn't build in cloud9 because of
> cmake requirements.
>
> ###
> ## global definitions
> ###
> #cmake_minimum_required(VERSION 3.1)
> cmake_minimum_required(VERSION 2.8)
> project(Corinthia)
>
> After changing to 2.8 It was fine.
> Is it possible to downgrade to 2.8? I did try "sudo apt-get install cmake"
> but the latest for my VM is 2.8
>
In order to compile 64bit for windows we use a new feature from cmake that
requieres 3.1
But we might be able to put a "if" around the cmake_minimum and in case of
cloud9 downgrade, I just need to find a CMAKE variable to test on.
rgds
jan I.
>
> franz
>
>
>
RE: Prototype web app, and Editor API
Posted by Franz de Copenhague <fr...@outlook.com>.
> -----Original Message-----
> From: Peter Kelly [mailto:pmkelly@apache.org]
> Sent: Friday, March 13, 2015 1:35 PM
> To: dev@corinthia.incubator.apache.org
> Subject: Re: Prototype web app, and Editor API
>
> Hi Franz, I’ve just committed your patch to the repository. I’m looking
> forward to seeing more on the python bindings!
>
After pulling the latest change I couldn't build in cloud9 because of cmake requirements.
###
## global definitions
###
#cmake_minimum_required(VERSION 3.1)
cmake_minimum_required(VERSION 2.8)
project(Corinthia)
After changing to 2.8 It was fine.
Is it possible to downgrade to 2.8? I did try "sudo apt-get install cmake" but the latest for my VM is 2.8
franz
Re: Prototype web app, and Editor API
Posted by Peter Kelly <pm...@apache.org>.
Hi Franz, I’ve just committed your patch to the repository. I’m looking forward to seeing more on the python bindings!
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> On 12 Mar 2015, at 12:42 pm, Franz de Copenhague <fr...@outlook.com> wrote:
>
>>> My fault with HTML email
>>>
>>> try:
>>>
>>>
>>> http://django-ckeditor-franzdecopenhague.c9.io/admin/demo_application/examplemodel/2/
>
>>>
>>
>> A short run and go test worked for me...will look more carefully later.
>>
>> rgds
>> jan i.
>>
>
> I have created my first Python binding patch http://bit.ly/19dpO54
> Please, let me know how to procedure and any feedback is welcome.
>
> So far, there are only 2 functions in the Python API.
>
> import dfutil
> Import dfconvert
>
> dfutil.normalize("other.html")
> dfconvert.get("input.docx", "output.html")
>
> jd
Re: Prototype web app, and Editor API
Posted by jan i <ja...@apache.org>.
On 12 March 2015 at 12:10, Peter Kelly <pm...@apache.org> wrote:
> > On 12 Mar 2015, at 12:42 pm, Franz de Copenhague <
> franzdecopenhague@outlook.com> wrote:
> >
> > I have created my first Python binding patch http://bit.ly/19dpO54
> > Please, let me know how to procedure and any feedback is welcome.
> >
> > So far, there are only 2 functions in the Python API.
> >
> > import dfutil
> > Import dfconvert
> >
> > dfutil.normalize("other.html")
> > dfconvert.get("input.docx", "output.html”)
>
> Wow, that was fast! I’m pleased to see you were able to put this together
> so quickly.
>
> For the record, I’m a big fan of Python too, and am using a lot for
> server-side functionality in my day job. So I’m all in favour of using it
> for our server-side code. (although I do lean towards Python 3, due to its
> unicode support).
>
> I’d like to merge in your patch, but I believe I need to confirm if you
> have previously signed an Apache contributor license agreement (
> http://www.apache.org/licenses/icla.txt <
> http://www.apache.org/licenses/icla.txt>) (can someone who’s been around
> a bit longer than me confirm whether patches like this require an ICLA, or
> this only required for commit access?).
>
We do not need a signed ICLA before Franz is invited to become a committer.
You (peter) can accept the patch with your committer hat on, review it, and
put it in master.
Usually people contribute patches (and are called contributors in the ASF
language), when the committers get tired applying the patches (or because
they see the work as valuable) the person is invited as committer, at that
point a ICLA must be signed.
> On the topic of API, as I think Jan has mentioned, we’re still somewhat
> undecided on exactly what the DocFormats API should look like, outside of
> the three basic conversion options (get, put, and create). For doing these
> conversions, I would actually suggest it would be useful (and safer) to
> launch dfconvert as an external process, so that in the event one is
> running a Python web server doing lots of conversions as people open/save
> documents, then in the event of the conversion process crashing, the web
> server will keep running and can simply report that there was an error
> during the conversion. That is, it wouldn’t bring down the whole python
> interpreter.
>
I see the 3 functions as the start of our API, so you are right now it
would be safer to launch dfconvert, but that would bring us nothing
short/medium term, whereas starting to integrate the function we need will
bring us a step further.
>
> However, I think it’s definitely desirable to have these functions
> accessible through a Python API as well, so that they can be used as part
> of a wide range of programs. And this is even more the case for other
> functions that do things like manipulate the document, using the HTML DOM
> and CSS APIs. There are all sorts of applications in this would be useful -
> such as a web application which accepts (or generates) forms to fill out
> that are in .docx format, and needs an easy way to get at the information
> in the forms. This is just one example.
>
> As you get to learn more about the library, I’d be interested to hear your
> thoughts on the API and what some of the scenarios you think it would be
> useful, outside of just conversion.
>
The same here.
rgds
jan i.
>
> —
> Dr Peter M. Kelly
> pmkelly@apache.org
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
>
Re: Prototype web app, and Editor API
Posted by Peter Kelly <pm...@apache.org>.
> On 12 Mar 2015, at 12:42 pm, Franz de Copenhague <fr...@outlook.com> wrote:
>
> I have created my first Python binding patch http://bit.ly/19dpO54
> Please, let me know how to procedure and any feedback is welcome.
>
> So far, there are only 2 functions in the Python API.
>
> import dfutil
> Import dfconvert
>
> dfutil.normalize("other.html")
> dfconvert.get("input.docx", "output.html”)
Wow, that was fast! I’m pleased to see you were able to put this together so quickly.
For the record, I’m a big fan of Python too, and am using a lot for server-side functionality in my day job. So I’m all in favour of using it for our server-side code. (although I do lean towards Python 3, due to its unicode support).
I’d like to merge in your patch, but I believe I need to confirm if you have previously signed an Apache contributor license agreement (http://www.apache.org/licenses/icla.txt <http://www.apache.org/licenses/icla.txt>) (can someone who’s been around a bit longer than me confirm whether patches like this require an ICLA, or this only required for commit access?).
On the topic of API, as I think Jan has mentioned, we’re still somewhat undecided on exactly what the DocFormats API should look like, outside of the three basic conversion options (get, put, and create). For doing these conversions, I would actually suggest it would be useful (and safer) to launch dfconvert as an external process, so that in the event one is running a Python web server doing lots of conversions as people open/save documents, then in the event of the conversion process crashing, the web server will keep running and can simply report that there was an error during the conversion. That is, it wouldn’t bring down the whole python interpreter.
However, I think it’s definitely desirable to have these functions accessible through a Python API as well, so that they can be used as part of a wide range of programs. And this is even more the case for other functions that do things like manipulate the document, using the HTML DOM and CSS APIs. There are all sorts of applications in this would be useful - such as a web application which accepts (or generates) forms to fill out that are in .docx format, and needs an easy way to get at the information in the forms. This is just one example.
As you get to learn more about the library, I’d be interested to hear your thoughts on the API and what some of the scenarios you think it would be useful, outside of just conversion.
—
Dr Peter M. Kelly
pmkelly@apache.org
PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
RE: Prototype web app, and Editor API
Posted by Franz de Copenhague <fr...@outlook.com>.
> > My fault with HTML email
> >
> > try:
> >
> >
> > http://django-ckeditor-franzdecopenhague.c9.io/admin/demo_application/examplemodel/2/
> >
>
> A short run and go test worked for me...will look more carefully later.
>
> rgds
> jan i.
>
I have created my first Python binding patch http://bit.ly/19dpO54
Please, let me know how to procedure and any feedback is welcome.
So far, there are only 2 functions in the Python API.
import dfutil
Import dfconvert
dfutil.normalize("other.html")
dfconvert.get("input.docx", "output.html")
jd
Re: Prototype web app, and Editor API
Posted by jan i <ja...@apache.org>.
On 11 March 2015 at 20:00, Franz de Copenhague <
franzdecopenhague@outlook.com> wrote:
>
>
> > Date: Wed, 11 Mar 2015 19:52:15 +0100
> > Subject: Re: Prototype web app, and Editor API
> > From: jani@apache.org
> > To: dev@corinthia.incubator.apache.org
> >
> > HI
> >
> > Just tried I got:
> >
> > Page not found (404) Request Method: GET Request URL:
> >
> http://django-ckeditor-franzdecopenhague.c9.io:80/admin/demo_application/examplemodel/2/username/password/
> >
> > example model object with primary key u'2/username/password' does not
> exist.
> >
> > You're seeing this error because you have DEBUG = True in your Django
> > settings file. Change that to False, and Django will display a standard
> 404
> > page.
> >
> >
>
> My fault with HTML email
>
> try:
>
>
> http://django-ckeditor-franzdecopenhague.c9.io/admin/demo_application/examplemodel/2/
>
A short run and go test worked for me...will look more carefully later.
rgds
jan i.
>
>
> -JD
>
>
RE: Prototype web app, and Editor API
Posted by Franz de Copenhague <fr...@outlook.com>.
> Date: Wed, 11 Mar 2015 19:52:15 +0100
> Subject: Re: Prototype web app, and Editor API
> From: jani@apache.org
> To: dev@corinthia.incubator.apache.org
>
> HI
>
> Just tried I got:
>
> Page not found (404) Request Method: GET Request URL:
> http://django-ckeditor-franzdecopenhague.c9.io:80/admin/demo_application/examplemodel/2/username/password/
>
> example model object with primary key u'2/username/password' does not exist.
>
> You're seeing this error because you have DEBUG = True in your Django
> settings file. Change that to False, and Django will display a standard 404
> page.
>
>
My fault with HTML email
try:
http://django-ckeditor-franzdecopenhague.c9.io/admin/demo_application/examplemodel/2/
-JD
Re: Prototype web app, and Editor API
Posted by jan i <ja...@apache.org>.
HI
Just tried I got:
Page not found (404) Request Method: GET Request URL:
http://django-ckeditor-franzdecopenhague.c9.io:80/admin/demo_application/examplemodel/2/username/password/
example model object with primary key u'2/username/password' does not exist.
You're seeing this error because you have DEBUG = True in your Django
settings file. Change that to False, and Django will display a standard 404
page.
After login with admin/admin
rgds
jan i.
On 11 March 2015 at 19:26, Franz de Copenhague <
franzdecopenhague@outlook.com> wrote:
>
>
> > From: peter@uxproductivity.com
> > Subject: Prototype web app, and Editor API
> > Date: Wed, 11 Mar 2015 16:56:58 +0000
> > To: dev@corinthia.incubator.apache.org
> >
> > Unfortunately I still haven’t found time to begin putting together the
> foundations of a proper web version of the Corinthia app, but I dug up an
> old version of a prototype I was experimenting with quite some time ago
> (before the code became open source). You can check it out here:
> >
> > http://web-demo.uxproductivity.com
> >
> > Username/password: demo/uxwrite
> >
> > Sometime in the next few days I hope to massage this into a cleaner
> format and get something into the repository. But if you’re keen to start
> looking into this now, doing a view source on this will give you an idea of
> how the web app could be implemented.
> >
> > Note that this demo just uses a pre-defined HTML document; there’s no
> server-side logic, ability to load & save files, or any integration with
> DocFormats. This was basically a proof of concept, but I think could give
> us some ideas for a starting point. Note also this is based on an old
> version of the editor code.
> >
> > Also, I’ve created a page on the wiki to document the API exposed by the
> Editor library (that is, the code in Editor/src) - see
> https://cwiki.apache.org/confluence/display/Corinthia/API+reference.
> These are the public functions intended to be used by a native app or other
> UI (e.g. browser-based). The prototype I mentioned above has the editor
> library and document being edited in an <iframe>, with all of the UI logic
> kept entirely separate from the library. Jan, I understand, is currently
> working on the necessary bindings for C++/Qt to talk to the library.
> >
> > I’ve just listed the functions so far without documentation. I’ll get to
> this as time permits, but if you’re looking for something relatively easy
> to get started on, some of you might like to have a look through the code
> and contribute documentation. All of the APIs are covered by the test cases
> (Editor/tests/*) so you can see examples here of how they are used.
> >
> > --
> > Dr. Peter M. Kelly
> > Founder, UX Productivity
> > peter@uxproductivity.com
> > http://www.uxproductivity.com/
> > http://www.kellypmk.net/
> >
> > PGP key: http://www.kellypmk.net/pgp-key <
> http://www.kellypmk.net/pgp-key>
> > (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
> >
>
> I just built an django example to prototype the server-side. It uses the
> CKEditor but we can replace it by DocFormats web editor
>
> http://django-ckeditor-franzdecopenhague.c9.io/admin/demo_application/examplemodel/2/
> username/password: admin/admin
> It is running in a developer python server, let me know if you cannot see
> the link.
> JD
RE: Prototype web app, and Editor API
Posted by Franz de Copenhague <fr...@outlook.com>.
> From: peter@uxproductivity.com
> Subject: Prototype web app, and Editor API
> Date: Wed, 11 Mar 2015 16:56:58 +0000
> To: dev@corinthia.incubator.apache.org
>
> Unfortunately I still haven’t found time to begin putting together the foundations of a proper web version of the Corinthia app, but I dug up an old version of a prototype I was experimenting with quite some time ago (before the code became open source). You can check it out here:
>
> http://web-demo.uxproductivity.com
>
> Username/password: demo/uxwrite
>
> Sometime in the next few days I hope to massage this into a cleaner format and get something into the repository. But if you’re keen to start looking into this now, doing a view source on this will give you an idea of how the web app could be implemented.
>
> Note that this demo just uses a pre-defined HTML document; there’s no server-side logic, ability to load & save files, or any integration with DocFormats. This was basically a proof of concept, but I think could give us some ideas for a starting point. Note also this is based on an old version of the editor code.
>
> Also, I’ve created a page on the wiki to document the API exposed by the Editor library (that is, the code in Editor/src) - see https://cwiki.apache.org/confluence/display/Corinthia/API+reference. These are the public functions intended to be used by a native app or other UI (e.g. browser-based). The prototype I mentioned above has the editor library and document being edited in an <iframe>, with all of the UI logic kept entirely separate from the library. Jan, I understand, is currently working on the necessary bindings for C++/Qt to talk to the library.
>
> I’ve just listed the functions so far without documentation. I’ll get to this as time permits, but if you’re looking for something relatively easy to get started on, some of you might like to have a look through the code and contribute documentation. All of the APIs are covered by the test cases (Editor/tests/*) so you can see examples here of how they are used.
>
> --
> Dr. Peter M. Kelly
> Founder, UX Productivity
> peter@uxproductivity.com
> http://www.uxproductivity.com/
> http://www.kellypmk.net/
>
> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
>
I just built an django example to prototype the server-side. It uses the CKEditor but we can replace it by DocFormats web editor
http://django-ckeditor-franzdecopenhague.c9.io/admin/demo_application/examplemodel/2/
username/password: admin/admin
It is running in a developer python server, let me know if you cannot see the link.
JD