You're right, there are a few issues with PST. Dave Hearnden and co. are fixing them up now.
On 7 January 2011 10:12, faisalbhagat <[email protected]> wrote: > in the PST generated code there are many issues The package > import > org.waveprotocol.box.common.comms.ProtocolAuthenticateMessages.*; > does not exists and is used in ProtocolAuthenticateMessage and there > are many classes which are referenced in these messages but are not > threre > for example ProtocolDocumentOperationMessage so i am unable to compile > these PST generated files. i will submit the code > when i will get the things going bit smoothly > > On Jan 6, 5:01 am, Alex North <[email protected]> wrote: > > On 5 January 2011 08:54, faisalbhagat <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > i have written new Version of RemoteViewServiceMultiplexer for > > > ConsoleClient in this i hv replaced all protocol requests to pst > > > generated code purely in java > > > like for open method. > > > > > public void open(WaveId id, IdFilter filter, WaveWSCallback stream) { > > > // Prepare to receive updates for the new stream. > > > streams.put(id, stream); > > > > > // Request those updates. > > > ProtocolOpenRequest.Builder request = > > > ProtocolOpenRequest.newBuilder(); > > > request.setWaveId(id.serialise()); > > > request.setParticipantId(userId); > > > for (String prefix : filter.getPrefixes()) { > > > request.addWaveletIdPrefix(prefix); > > > } > > > for (WaveletId wid : filter.getIds()) { > > > request.addWaveletIdPrefix(wid.getId()); > > > } > > > > > socket.sendMessage(request.build(), null); > > > } > > > > > Now the next step i have is that socket which i have in > > > RemoteViewServiceMultiplexer is WaveWebSocketClient its methods are > > > again > > > expecting JSON objects . For example socket.sendMessage i m writing > > > console verision of WaveWebsocketClient > > > > > i have written send Message in it like that. > > > > > public void sendMessage(GeneratedMessage message, > > > SubmitResponseCallback callback) { > > > int seqNo = sequenceNo++; > > > StringBuffer buffer=new StringBuffer("{"); > > > buffer.append("version:1"); > > > buffer.append(","); > > > buffer.append("sequenceNumber:"+seqNo); > > > buffer.append(","); > > > if(message instanceof ProtocolOpenRequest) > > > { > > > buffer.append("messageType:ProtocolOpenRequest"); > > > }else > > > if(message instanceof ProtocolSubmitRequest) > > > { > > > buffer.append("messageType:ProtocolSubmitRequest"); > > > }else if(message instanceof ProtocolSubmitRequest) > > > { > > > > buffer.append("messageType:ProtocolAuthenticateRequest"); > > > } > > > buffer.append("'"); > > > buffer.append("messageJson:"+message.toByteArray()); > > > buffer.append("}"); > > > send(buffer.toString()); > > > } > > > > > m i right? > > > > This last bit looks like it's duplicating the work that auto-generated > PST > > classes should do. You shouldn't need to do any string building. > > > > The PST generated classes are in build/messages/... > > > > Can you export your changes as a code review so we can see the extent of > > what you're attempting and its context? Follow the instructions here: > http://www.waveprotocol.org/code/submitting-code(even though you won't > > necessarily submit the changes right away). > > > > Alex > > > > > > > > > > > > > > > > > > > > > On Jan 4, 9:24 am, Alex North <[email protected]> wrote: > > > > No, Piotr's working around it. > > > > > > It's an open task if someone wants to take it, but I'll also put it > on my > > > > mental task list somewhere high up. > > > > > > A. > > > > > > On 4 January 2011 15:17, Alex North <[email protected]> wrote: > > > > > > > Ah, bummer. I had postponed updating files to use PST messages > because > > > I > > > > > was going to throw a bunch out after implementing the newer C/S > > > protocol. > > > > > However that is stuck behind a queue of hairy yaks. Piotr Kaleta > was > > > also > > > > > running up against problems here so may make that update. Or maybe > I > > > should > > > > > just do it. > > > > > > > A. > > > > > > > On 4 January 2011 10:13, David Hearnden <[email protected]> > wrote: > > > > > > >> You might be stuck there right now. > > > > > > >> You're right, ProtocolOpenRequest is a generated GWT-based > > > > >> implementation of the OpenRequest protocol buffer. We've replaced > the > > > > >> previous generation tool with a new one, called PST, and the new > tool > > > > >> generates plain Java implementations of the message types (in > addition > > > > >> to the GWT Javascript ones). Once RemoteViewServiceMultiplexer is > > > > >> updated to use the new messages types, then that should unblock > you. > > > > > > >> I'm not sure who is actively working on updating all the code to > use > > > > >> the new message types, so I can't give an accurate ETA for it, but > > > > >> Alex will know. I suspect it won't be very long. > > > > > > >> -Dave > > > > > > >> On Jan 3, 8:54 am, faisalbhagat <[email protected]> wrote: > > > > >> > i hv startd refactoring the client. in > > > RemoteViewServiceMultiplexer's > > > > >> > method > > > > >> > public void open(WaveId id, IdFilter filter, > WaveWebSocketCallback > > > > >> > stream) { > > > > >> > // Prepare to receive updates for the new stream. > > > > >> > streams.put(id, stream); > > > > > > >> > // Request those updates. > > > > >> > ProtocolOpenRequest request = ProtocolOpenRequest.create(); > > > > >> > request.setWaveId(id.serialise()); > > > > >> > request.setParticipantId(userId); > > > > >> > for (String prefix : filter.getPrefixes()) { > > > > >> > request.addWaveletIdPrefix(prefix); > > > > >> > } > > > > >> > // Issue 161: > > > > >>http://code.google.com/p/wave-protocol/issues/detail?id=161 > > > > >> > // The box protocol does not support explicit wavelet ids in > the > > > > >> > filter. > > > > >> > // As a workaround, include them in the prefix list. > > > > >> > for (WaveletId wid : filter.getIds()) { > > > > >> > request.addWaveletIdPrefix(wid.getId()); > > > > >> > } > > > > >> > socket.sendMessage(request, null); > > > > >> > } > > > > > > >> > i cant use ProtocolOpenRequest because it is javasccript based > > > doesnt > > > > >> > work in console client. can you suggest me what to do with it. > > > should > > > > >> > i write java version of this class along with all the classes in > the > > > > >> > package or use the classes in > > > > >> > org.waveprotocol.box.common.comms.WaveClientRpc? > > > > > > >> > On Dec 29 2010, 6:52 am, Alex North <[email protected]> wrote: > > > > > > >> > > Actually, no. The CoreWaveViewData is also old and deprecated. > It > > > > >> exists > > > > >> > > only to host the index wave, which is on the way out. > Apologies > > > again > > > > >> for > > > > >> > > all this deprecated code around the place, some of it not > > > explicitly > > > > >> marked. > > > > >> > > WIAB development has been going for a long time (initially as > the > > > > >> "FedOne" > > > > >> > > example server). The new wave panel "undercurrent" replaced > much > > > of > > > > >> the data > > > > >> > > types and protocols with those more closely based on Google > Wave's > > > > >> > > implementations, which are a bit more complex but much more > > > capable. > > > > > > >> > > The (modern) web client is implemented in stages. StageTwo has > > > much of > > > > >> the > > > > >> > > communications code. StageTwo.createConnector() demonstrates > how > > > to > > > > >> wire up > > > > >> > > the communications stack, though some parts of it are > web-client > > > > >> specific, > > > > >> > > so it's not a direct copy/paste for the console client. But > you do > > > > >> want to > > > > >> > > build an OperationChannelMultiplexer and build the data from > there > > > > >> > > (LiveChannelBinder.openAndBind()). > > > > > > >> > > HTH, > > > > >> > > A > > > > > > >> > > On 24 December 2010 22:51, faisalbhagat < > [email protected]> > > > > >> wrote: > > > > > > >> > > > in the console client the class aroung which functionality > > > revolves > > > > >> it > > > > >> > > > ClientWaveView > > > > >> > > > and in web client it is WebClientWaveView. The main > difference > > > in > > > > >> > > > betwean these two > > > > >> > > > is datatype for collection of wavelets. In WebclientWaveView > it > > > is > > > > >> > > > CoreWaveViewData and in > > > > >> > > > ClientWaveView it is WaveViewData. i think i should start > with > > > > >> > > > replacing WaveViewData with Core > > > > >> > > > WaveViewData and then follow its ripple effects. > > > > > > >> > > > On Dec 23, 5:37 am, Alex North <[email protected]> wrote: > > > > >> > > > > Great - I'm glad you're keen. > > > > > > >> > > > > At a broad level, all the code in o.w.box.client > implements a > > > > >> backend > > > > >> > > > > communication that doesn't use the wave model well. All > that > > > code > > > > >> exists > > > > >> > > > > only for the console client (I think I'll move it to the > > > > >> consoleclient > > > > >> > > > > package). It should be deleted, and replaced with code > > > re-using > > > > >> that used > > > > >> > > > by > > > > >> > > > > the web client. > > > > > > >> > > > > On 23 December 2010 00:20, faisalbhagat < > > > [email protected]> > > > > >> wrote: > > > > > > >> > > > > > alex > > > > >> > > > > > i want to take on this task. for this i need your help > of > > > and > > > > >> on. can > > > > >> > > > > > you guide me from where to start? which things are going > to > > > be > > > > >> > > > > > replaced by this conversation moddel and where? m sory > for > > > this > > > > >> type > > > > >> > > > > > of question m kind of newbie here :-> > > > > > > >> > > > > > On Dec 15, 5:44 am, Alex North <[email protected]> > wrote: > > > > >> > > > > > > A blip is an abstract conversation model concept, not > just > > > a > > > > >> > > > document. > > > > >> > > > > > > Deleting a blip requires clearing its content and > removing > > > the > > > > >> > > > > > corresponding > > > > >> > > > > > > entry from the conversation manifest document. > > > > > > >> > > > > > > The conversation model code > (o.w.wave.model.conversation) > > > > >> expresses > > > > >> > > > this, > > > > >> > > > > > > but unfortunately the console client pre-dates the > > > > >> conversation > > > > >> > > > model. > > > > >> > > > > > There > > > > >> > > > > > > is a significant refactor required before this becomes > a > > > > >> simple > > > > >> > > > change. > > > > >> > > > > > It > > > > >> > > > > > > would be fantastic if someone were to take this on; > the > > > first > > > > >> step > > > > >> > > > would > > > > >> > > > > > be > > > > >> > > > > > > to replace the console client's manual manipulations > with > > > use > > > > >> of the > > > > >> > > > > > > conversation model code. > > > > > > >> > > > > > > A. > > > > > > >> > > > > > > On 15 December 2010 01:47, faisalbhagat < > > > > >> [email protected]> > > > > >> > > > wrote: > > > > > > >> > > > > > > > egarding adding the updation and deletion facility > in > > > > >> console > > > > >> > > > client. > > > > ... > > > > read more ยป > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
