Closed johntdowney closed 6 years ago
Hi there.
The COPY operator is really only preliminary. I don't really know if it's working.
That said, it's not intended to insert into the middle of strings. It can only copy from and paste/overwrite a value that is a single element of an array, a single character of a string, or a property of an object.
Can I ask what you're working on?
Sure, it's for this website I'm working on, www.touchstonememories.com. JOT isn't implemented in its current build, but a similarly structured system is, albeit without any real attempt at conflict resolution. It's operations are highly specific, too, and not well-structured, generalized operations like those in JOT.
Basically it gives users a drag-and-drop web interface to create and edit their own custom hardcover books, in the form of fairly simple JSON objects stored in an AWS S3 bucket. The server takes a book JSON object and generates a layout from it, and that's used to render the book to the browser or a PDF file, cover and all. From there, physical copies can be purchased and we'll print them as hard cover books at our print shop and ship them to the customer.
More specific to the problem I posted, for user text input, it uses contenteditable elements and converts the user-generated html content to the quill delta format, allowing for users to user some limited rich text features like bold and italics. Their text data is stored in this format, as opposed to HTML, and is used in generating the book layouts. So when users are editing their bits of HTML, quill operations are recorded that represent the changes they make and then I wrote a function to take a quill operation and the document before the operation is applied and returns a JOT operation that does the same thing to the quill-formatted text data.
Hopefully that makes sense. In any case, I don't think it's a deal breaker and I can get around it. Maybe by changing from the quill format to a different format more amenable to JOT, or by just taking the hit and leaving the quill operations unoptimized and making sure that the quill-to-JOT converter I wrote does its best to choose the optimal set of JOT changes to make such that the insert properties of the quill operations don't get concatenated together and the number of resulting quill operations is minimized.
Also, I'm glad you responded, as I was considering finding your email and contacting you to ask if my use case fell within the GNU GPLv3 this code is released under such that the JavaScript being publicly available is sufficient and all the other Java code doesn't need to be open source. I've read through the license and some message board postings on the topic but found conflicting answers and it's still not clear. I'm banking on that it's not, and if so I'll refrain from using it without also releasing all that code (but I can't really do that, so will have to switch to another alternative or forge my own). I can't say that I won't use the basic ideas of this module as a starting point while recreating the wheel if it comes to that, though, because I'm really impressed by the simplicity and utility of JOT. It fits like a glove on the website, so far.
Oops, closed this and then realized I asked another question and I was hoping for a response from you, so re-opened it.
Hey. Sorry for the delay (just busy).
That's pretty cool what you're doing and seems like a great use case. Keep in mind that JOT may or may not actually be working, though, and if it doesn't work you could end up with corrupted data! I've had some good luck with it etc etc but I wouldn't be ready to say that the whole package is ready for prime time.
As for the license, I'm happy to simply grant you a license to use JOT for your product, as you described. I want people to use JOT, after all, but I'm also trying to keep my options open for a business model. (Also, not that I would ever sue you, but re-creating a substantially similar library based on what you've seen in JOT could still fall under copyright protection, I believe.)
Josh, love the work, but in light of what you just said, I think it might be a good idea to clarify your licensing intentions more.
I'm looking for a Google realtime API replacement for youmescript.com (12,000 weekly users), and I'm willing to do a lot of work in the next 9 months to help bring whatever I choose up to scratch. But this is how I earn my meager living, and I'm not going to open-source the rest of the client-side code (the whole thing is client-side).
JS and the GPL have always been really uncomfortable bedfellows, so (especially if you have your own future commercial / proprietary intent for JOT), you should let us know now whether we can expect a license which will allow proprietary uses where only the JOT/JOT-derived source code is open... and thus whether JOT is worth pursuing or working on. Thanks!
Hey Jake. Thanks for your question. I'm sure we can work something out. My goal is to get JOT to be used, and ideally in the long run for it to have a revenue model around it because I don't have time to be working on this as a hobby. I didn't choose GPL because I want to start an open source project (I do enough of that on other projects), but because I wanted to post the source code without giving it all away. So if you're not working on an open source project, that makes things easier!
Since I own all of JOT, I can also just write a new license for you so you can use it under other terms we agree on and not worry about the GPL at all. I'm not interested in making any money off of early users, especially if you'd be willing to share any improvements you make to JOT with me.
For either of you, if you'd like to discuss further, it'd probably best to move to email. I'm jt@occams.info.
Thanks for your interest!
First off, great module – well-thought-out, well-executed, compatible in Java Nashorn, and simple to use!
I'm writing some code to go between quill's delta format and the JOT delta format.
While doing this, I'd like to create a set of JOT operations that optimize a JSON object that looks like this:
[ {"insert":"abcd"}, {"insert":"efg"} ]
By combining the two insert operations into a single operation like so:
[ {"insert":"abcdefg"} ]
It somewhat works to do this by splicing in the 3 "efg" characters and then removing the 2nd insert operation, but for my purposes that would seem to be logically inconsistent and may overwrite any changes made to the "efg" string by someone else during the rebase process. The intention is to move the 2nd insert property string to the end of the 1st insert property string, not to delete it and explicitly paste in "efg", and conflicting changes to "efg" might be lost by doing that. If the COPY operator works like I assume it does, it would be better to use it to work as a reference to the "efg" string instead, and then remove the 2nd object in the array.
Except I can't seem to find a way that lets me do something like this:
new jot.COPY([['/1/insert', '/0/insert/4']])
Where the /4 here denotes that the entire source string "efg" should be copied and inserted after the 4th character of the "abcd" string (this is the part that doesn't work and may simply be because I don't know the correct JSON pointer syntax because this obviously isn't it). Is this a limitation of JOT or JSON pointers, or is there some way to do this? It would seem to fit right into the existing JOT framework.