On 29 May 2011 21:52, Adrian Cochrane <[email protected]> wrote: > How about HTML with plenty of pseudocode and clear semantics (a dl tree, > for libraries, etc). I'll be comfortable with that, and then we can > agree on who'll implement it. I don't want to be creating another > implementation for the standards, we can test it in our own projects.
Client side, I'm happy to test in my project - but there needs to be a server end to connect too in order to do that! > > ShareJS is JavaScript both sides with node.js. > -- > Adrian Cochrane > [email protected] > > > On Sun, 29 May 2011 11:55 -0500, "Perry Smith" <[email protected]> > wrote: >> >> On May 29, 2011, at 10:14 AM, Thomas Wrobel wrote: >> >> > On 29 May 2011 16:15, Perry Smith <[email protected]> wrote: >> >> Java and Python frustrate and scare me. Python has lots of issues >> >> between even minor versions. Java has issues between platforms. In both >> >> of these languages, I've never had a pleasant user or developer >> >> experience. >> >> >> >> I was going to suggest Ruby but didn't because I knew this was a >> >> Python/Java group. >> >> >> >> Would it be insane to have parallel implementations? That way, we would >> >> work out and clearly document any language specific details that might >> >> get hidden. >> > >> > Not insane - but I think we need one testable primary implementation >> > to deal with the "generic" bugs and issues that arise as the c/s is >> > developed before the implementation specific bugs. >> > >> > The more I think however I'm not sure we can avoid either java or >> > python - at least for the server side. We need to plug into an >> > existing server as I cant think of another way to develop a c/s for a >> > wave server. (and we dont want to have to make our own server!). Not >> > sure of any options really :? >> > >> > We could, however, have anything we like for client-side code examples. >> >> If the majority of the client side is going to actually use javascript, >> then lets use that on the client side. >> >> I wonder... can Rhino[1] hook in to another Java application? Then we >> could use javascript on both sides and still test. >> >> [1] http://www.mozilla.org/rhino/ >> >> > >> >> On a different topic, can you point me to the POW work? Is that using >> >> Python in place of Java for the entire implementation? >> >> >> >> On May 29, 2011, at 8:50 AM, Thomas Wrobel wrote: >> >> >> >>>> Can this be done as a very well documented and commented piece of code >> >>>> that actually runs? I can understand > code far quicker than I can >> >>>> understand TechSpeak. >> >>>> >> >>> >> >>> +1 >> >>> >> >>>> Pick a language like C (not Java or C++). Something that clearly shows >> >>>> precise intent. It can be a pseudo >> >>>> language but then we can't test it by running it. >> >>> >> >>> I essentially don't know any C, but I certainly approve of usable code >> >>> so I guess I could try to learn unless as nothing too language >> >>> specific is needed. >> >>> >> >>> In the end though someones going to have to convert it to Java needed >> >>> for wiab, python for POW and Javascript for webclients side no? >> >>> Downside of C for a c/s example lib might be no easy testing as theres >> >>> no server written in C? >> >>> >> >>>> >> >>>> After we're done, we'd not only have a spec but also something useful >> >>>> -- working code. >> >>>> >> >>>> On May 29, 2011, at 7:09 AM, Thomas Wrobel wrote: >> >>>> >> >>>>> Well, thats the problem, I haven't either ;) >> >>>>> I'm currently contributing a bit to the w3c POI standard, but its more >> >>>>> general advice on whats needed/useful for AR then solid contributions. >> >>>>> My experience is pretty low really, feeling my way. >> >>>>> I also don't know anything really about protocols beyond my own >> >>>>> bespoke stuff. >> >>>>> >> >>>>> regarding the name; I'm not sure thats such a good idea as its a bit >> >>>>> confusable with the "wave federation protocol" itself no? The c/s >> >>>>> standard might be similar in some ways but it wont be the same. >> >>>>> >> >>>>> >> >>>>> >> >>>>> On 29 May 2011 13:24, Adrian Cochrane <[email protected]> wrote: >> >>>>>> Oh, and Thomas Wrobel, I'd appreciate your help. I've never written a >> >>>>>> real standard before. >> >>>>>> >> >>>>>> How about dropping the "Con". "The Federation", less Firefly more >> >>>>>> Wave. >> >>>>>> -- >> >>>>>> Adrian Cochrane >> >>>>>> [email protected] >> >>>>>> >> >>>>>> >> >>>>>> On Sun, 29 May 2011 04:05 -0700, "Adrian Cochrane" <[email protected]> >> >>>>>> wrote: >> >>>>>>> Well, I just thought that if the name Wave came from Firefly, so >> >>>>>>> should >> >>>>>>> it's concertium. >> >>>>>>> >> >>>>>>> To be clear, I'd take the task of reworking the standards by placing >> >>>>>>> my >> >>>>>>> current plans online and taking all the criticism I can. >> >>>>>>> >> >>>>>>> As for using the original standards, it's just because then I wasn't >> >>>>>>> reworking the standards. As for Federation, I'd like that to be >> >>>>>>> simalor >> >>>>>>> to the current standard (since it's the architecture of PyOfWave). >> >>>>>>> -- >> >>>>>>> Adrian Cochrane >> >>>>>>> [email protected] >> >>>>>>> >> >>>>>>> >> >>>>>>> On Sun, 29 May 2011 12:54 +0200, "Thomas Wrobel" >> >>>>>>> <[email protected]> >> >>>>>>> wrote: >> >>>>>>>> Like call it Moya then, from Farscape ;) >> >>>>>>>> (hay, it did last longer....) >> >>>>>>>> >> >>>>>>>> On 29 May 2011 12:52, Paul Thomas <[email protected]> wrote: >> >>>>>>>>> face palm. more firefly references...ominous :/ >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> ________________________________ >> >>>>>>>>> From: Adrian Cochrane <[email protected]> >> >>>>>>>>> To: [email protected] >> >>>>>>>>> Sent: Sun, 29 May, 2011 9:58:12 >> >>>>>>>>> Subject: protocols >> >>>>>>>>> >> >>>>>>>>> avid Hearnden <[email protected]> Wed, May 25, 2011 at 8:36 >> >>>>>>>>> AM >> >>>>>>>>>> Reply-To: [email protected], [email protected] >> >>>>>>>>>> To: wave-dev <[email protected]> >> >>>>>>>>>> There is a technical roadmap (i.e., rich design docs etc, >> >>>>>>>>>> published >> >>>>>>>>>> somewhere on the site - let me know if you can't find them) for a >> >>>>>>>>>> new >> >>>>>>>>>> protocol that overcomes many of the issues with the current one, >> >>>>>>>>>> and works >> >>>>>>>>>> much better with more advanced features (e.g. diff-on-open). I >> >>>>>>>>>> don't think >> >>>>>>>>>> it's a moving target - the doc has been ready for a few months, >> >>>>>>>>>> and I don't >> >>>>>>>>>> think anyone has significant changes to it in mind. However, >> >>>>>>>>>> AFAIK, nobody >> >>>>>>>>>> who's available has signed up to do the work, so there is no >> >>>>>>>>>> timeline for >> >>>>>>>>>> it. I was keen to get into it a few months back, and Alex North >> >>>>>>>>>> was too, >> >>>>>>>>>> but both our availabilities have significantly diminished. It's >> >>>>>>>>>> probably >> >>>>>>>>>> about 2-3 weeks of work for someone to see it through end to end >> >>>>>>>>>> though. It >> >>>>>>>>>> was previously blocked by a few things that have now been >> >>>>>>>>>> implemented. >> >>>>>>>>> >> >>>>>>>>>> I would strongly encourage not building too much on the current >> >>>>>>>>>> protocol, >> >>>>>>>>>> since it has a number of known limitations. The new protocol is >> >>>>>>>>>> simpler and >> >>>>>>>>>> achieves a better separation of functionality. If there are a >> >>>>>>>>>> few people >> >>>>>>>>>> (PyOfWave?) with the will and a bit of time, then it is very >> >>>>>>>>>> achievable to >> >>>>>>>>>> get it rolled out. >> >>>>>>>>> >> >>>>>>>>>> -Dave >> >>>>>>>>> >> >>>>>>>>> I will be proud to go over it, but (because I want to be liberal) >> >>>>>>>>> I'd >> >>>>>>>>> first ask to start >> >>>>>>>>> with a forum or mailing list which I'd refer to as 'The >> >>>>>>>>> Confederate' >> >>>>>>>>> after Firefly T.V. >> >>>>>>>>> series which gave Wave it's name. I've already exchanged some >> >>>>>>>>> messages >> >>>>>>>>> with josephg on GitHub on >> >>>>>>>>> the shareJS Wave project on this. >> >>>>>>>>> >> >>>>>>>>> What I planned to work with, if I didn't get proper >> >>>>>>>>> standardization, is >> >>>>>>>>> the extended original >> >>>>>>>>> standards (to make up for some lacking features I say), a non-HTTP >> >>>>>>>>> alternative to Simple Data >> >>>>>>>>> Protocol, an fully designed Gadget API in a derivative of >> >>>>>>>>> CoffeeScript >> >>>>>>>>> (to simplify offline clients), >> >>>>>>>>> and a URL scheme to serve for embedding, WaveThis, and a alias >> >>>>>>>>> query for >> >>>>>>>>> groups. >> >>>>>>>>> >> >>>>>>>>> I'll get started on it provided that I am provided with the >> >>>>>>>>> necessary >> >>>>>>>>> information on how to do >> >>>>>>>>> it. However on my project, I've got some work on PyOfWave to >> >>>>>>>>> finish. >> >>>>>>>>> -- >> >>>>>>>>> [email protected] >> >>>>>>>>> >> >>>>>>>>> -- >> >>>>>>>>> http://www.fastmail.fm - Email service worth paying for. Try it >> >>>>>>>>> for free >> >>>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> http://www.fastmail.fm - Does exactly what it says on the tin >> >>>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> http://www.fastmail.fm - One of many happy users: >> >>>>>> http://www.fastmail.fm/docs/quotes.html >> >>>>>> >> >>>>>> >> >>>> >> >>>> >> >> >> >> >> > > -- > http://www.fastmail.fm - Send your email first class > >
