I suppose we are getting a little off topic but..
I had been advocating switching to maven from ant a while back. One of the things that this would help with is the unit testing. Right now any check in really requires all unit test to be rerun. If we leverage maven then we can break things up in to modules, where the unit test are tied to the module. That way when you change code in a module, only its unit test need to be run. That said, the current ant based build is pretty complicated. I suspect that switching to maven would be a pretty disruptive task. We would definitely need to plan it out. We would need to decide what the appropriate module design is, pick group and artifact ids, and plan a timeframe to do the cut over. We would likely need a mini code freeze to get this done. ~Michael On Apr 11, 2011, at 8:04 AM, Yuri Z. wrote: > Nelson, I personally have no objections for using Maven to manage > dependencies. If you can submit a patch it would be great. > Yuri > > Sent from my iPhone > > On 11 באפר 2011, at 16:28, Nelson Silva <[email protected]> wrote: > >> I believe WAIB should be split into modules. If we adopted Maven as build >> tool it would really make things a lot simpler. >> We should have pure api modules and then default impl packages. This would >> allow anyone to contribute sample client, server, etc implementations which >> could then be integrated into WAIB. >> >> On 11-04-2011 14:07, Thomas Wrobel wrote: >>>> On of the current things with WiaB seems to be that the server and client >>>> are all rolled in to one. For people wanting desktop clients, mobile >>>> clients, etc, I think it is critical to have a well defined protocol for >>>> the client and server to work together. >>>> >>>> ~Michael >>> >>> Couldn't possibly agree more with that! >>> It would be nice if client development could be done relatively >>> independently from server development, I think both would proceed >>> faster if they wernt so tied together. >>> >>> -Thomas >>> >>>> On Apr 9, 2011, at 3:32 PM, Thomas Wrobel wrote: >>>> >>>>> Remember there is strong pro XMPP voices here too; >>>>> http://www.process-one.net/en/blogs/article/xwave_a_tribute_to_google_wave_team/ >>>>> >>>>> I'm not sure who is right on a technical sense, but there is working >>>>> xmpp based federations out there, are their any based on http? >>>>> >>>>> Regarding the c/s protocol - it makes somewhat sense anyway if it was >>>>> more or less the same as the server/server one, seeing as they both >>>>> basically have to exchange the same information to keep the document >>>>> in sync. >>>>> >>>>> As I suggested on the recent poll,however, I think separating out the >>>>> wiab webclient and using a lib for c/s protocol would help a lot. That >>>>> way , even if different choices are made for the protocol later on, >>>>> its just the lib that has to be changed. People could thus make >>>>> clients with the protocol itself abstracted away. >>>>> >>>>> ~~~~~~ >>>>> Reviews of anything, by anyone; >>>>> www.rateoholic.co.uk >>>>> Please try out my new site and give feedback :) >>>>> >>>>> >>>>> >>>>> On 10 April 2011 00:13, Michael MacFadden<[email protected]> >>>>> wrote: >>>>>> Nelson, >>>>>> >>>>>> There has been large debate on XMPP in wave. The general complaint is >>>>>> that the protocol is to verbose. My two cents are that one of the main >>>>>> points of XMPP was a verbose XML human readable protocol with standard >>>>>> extension mechanisms. However wave uses protobufs and base64 encodes >>>>>> all the data in the XMPP stanzas. The data exchanged by wave is not >>>>>> human readable, xml based, or part of the XMPP standard. That defeats >>>>>> the purpose of using the XMPP standard in the first place. In my >>>>>> opinion this basically relegates XMPP to just a delivery envelope, and >>>>>> one that adds on a lot of overhead. >>>>>> >>>>>> Also XMPP's dependance on long lived TCP connections to maintain the xml >>>>>> stream, there are difficulties providing services to clients that are >>>>>> frequently disconnected. For these reasons there is talk of adding a >>>>>> "raw" http transfer mechanism for federation. Until that is worked out >>>>>> I would hesitate to entertain the idea of injecting XMPP in to the c/s >>>>>> protocol. >>>>>> >>>>>> ~Michael >>>>>> >>>>>> On Apr 9, 2011, at 2:51 PM, Nelson Silva wrote: >>>>>> >>>>>>> XMPP over websockets was proposed as a draft >>>>>>> (http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-00) and >>>>>>> ejabberd now has a sample module to support it: >>>>>>> >>>>>>> http://blog.superfeedr.com/xmpp-over-websockets/ >>>>>>> >>>>>>> Wouldn't it be great to use XMPP for both C/S and federation ? or is it >>>>>>> too verbose ? >>>>>>> >>>>>>> Just wanted to share this with the list. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Nelson >>>>>> >>>> >>
