Menu
▾
▴
convey-developers — Convey Developers
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(58) |
Sep
(6) |
Oct
(3) |
Nov
(9) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(59) |
Aug
(56) |
Sep
(8) |
Oct
(3) |
Nov
|
Dec
|
|
From: eD B. <edb...@ca...> - 2003-08-06 01:10:30
|
Hi Andy, You mentioned that the JTabbedPaneWithCloseTabs should remove the canvas from the Hash table when canvas gets removed from frame. However, I don't even see where it's being added to a table. Could you enlighten me on this? Maybe you dealt with it already. Thanks, Ed |
|
From: eD B. <edb...@ca...> - 2003-08-05 21:47:15
|
Hey Scott. Really great insights in your recent emails. I included some
comments below.
Ed
On Monday, August 4, 2003, at 10:47 PM, Scott Luan wrote:
> Hi Andy,
>
> Thanks for your response. :-)
>
> I think that the two options discussed earlier relate to more than a
> "pen"-vs-"free-for-all" distinction. What I was trying to get at in
> my earlier emails (and which I can't find on the developers'
> discussion board), and perhaps didn't make clear, is that the kind of
> transactional scheme (how clients' canvases get updated) may
> ultimately relate to the reuseability of the Convey technology.
> Specifically, it may be really nice if the Jabber messages are not in
> the form of SVG or Convey specs;
We are currently straying from the SVG spec for handling graphic change
events, SVG is also XML, and we are currently using an XML parser. I
guess I don't understand what you mean by 'generic XML'. I think we had
intended to make Convey very pluggable so that if someone wanted to use
it for a particular kind of collaboration not currently supported, they
would create a plug-in that would include a Bridge Factory component
for conversion of their new XML elements.
> communicating in the generic format of XML doc diffs may have some
> problematic aspects, but I think it would be a worthwhile endeavor
> since this mode of communiation may apply to all kinds of XML
> representations.
> Therefore, also directly relevant is how Convey would be extended for
> other kinds of canvas markings. The XML-diff method, I believe, not
> only tries to address the problems of concurrency and non-sequential
> messages but also concerns about reuseability.
Good point.
> Perhaps this is getting ahead of ourselves, but, yes, let's keep the
> discussion open. :-)
>
> About that timestamp ... what I had in mind is that each client would
> keep a running time-count which is sync'ed only once when it connects
> to a chatroom.
> All messages sent by this client would be timestamped before it
> reaches the Jabber server.
Yeah, I was thinking clients could be sync'ed up once from the server
(where the chatroom is hosted) and then a time-stamp would be the time
difference between sync-time and the time the event occurred. This
would be determined client-side but used server-side for event
sequencing. I was reading in a book on Jabber that most functionality
should be server side so that the clients are kept light weight. This
time syncing strategy seems to adhere to that recommendation.
I know there are still concurrency problems with this approach due to
connection speeds. Is there really information in the packet data that
would be the ultimate arbitrator for such situations?
> The time sync may be coordinated with the chatroom initiator, the
> Jabber server, or some reliable machine on the internet. The problem
> which I believe we need to address is how to eliminate resulting
> biases caused by different client connection speeds -- how to
> compensate for the time-sync packet travel time may involve digging
> into the packet for the appropriate data.
>
> Scott
>
>
>> From: "Andy Ames" <ag...@sb...>
>> Reply-To: con...@li...
>> To: <con...@li...>
>> Subject: RE: [convey-developers] concurrency model
>> Date: Mon, 4 Aug 2003 12:25:49 -0700
>>
>> Scott,
>>
>> Thank you for the thorough reply. Your descriptions of the problem
>> are easy
>> to read and follow.
>>
>> Your description of resolving conflicts retroactively based on a
>> timestamp
>> parallels the diff, patch, and cvs programs. We could probably base
>> our
>> solutions on the ideologies of these programs.
>>
>> A diff file is analogous to our Graphic event. In a diff file, you
>> can have
>> lines added, changed, or removed. A New Graphic event is lines added,
>> a
>> Delete Graphic event is lines removed, and a Graphic Change event is
>> lines
>> changed.
>>
>> A diff may be applied to a file using the patch command. This command
>> can
>> take timestamps into account when applying multiple patches.
>>
>> Some other issues we'd need to solve with this scenario:
>>
>> 1) Who generates the timestamps? The jabber protocol does have an
>> extension
>> (that I believe is well-supported) for producing timestamps using
>> GMT. Also,
>> with our diff/patch analogy, the patches are intended to be sent out
>> from
>> the core team. Generally, when many developers are making changes and
>> submitting patches, there needs to be a "resolver" of conflicts. This
>> implies that we still would need a client to act as "resolver."
>>
>> Or might I be wrong with this assumption. I guess we'd need to look
>> at the
>> Jabber spec regarding timestamps. If the timestamp is guarenteed to be
>> generated by the same host for all messages in a chat session or
>> one-on-one
>> session, then each client can be the resolver on its own. If this is
>> the
>> case, it leads to the next issue (which I believe you touched on).
>>
>> 2) When a client (R1) (presumably faster than the rest) sends a
>> message
>> f1(object) at time t1 and another client (R2) (presumably slower)
>> sends a
>> message f2(object) at time t2, where t1 < t2, then client (R2)
>> doesn't even
>> know what the timestamp, t2 is of the message that it sent! Client
>> (R2)
>> would need to be notified by the host of the timestamp, t2, its
>> message was
>> given, so that (R2) can resolve all further incoming messages, such as
>> f1(object).
>>
>> To give us some context, I'd like to point out that what we are
>> trying to
>> solve here, is how to do a "free-for-all" collaboration session. We
>> coined
>> this term a while ago and differentiated it from a "moderated"
>> collaboration
>> session. The latter is controlled by the "pen" concept. Whoever has
>> the
>> "pen" can modify the canvas. No one else can until they have the pen.
>> The
>> pen is controlled by the session host or initiator.
>>
>> The "pen" may also be controlled algorithmically in some situations
>> such as
>> turn-based board games and RPGs.
>>
>> The "pen" solution is useful for moderated discusssions such as
>> tutoring and
>> other formal collaboration. It seems the "free-for-all" mode is really
>> useful just for fooling around. It may be too problematic to be
>> practical.
>>
>> The foreseeable use of "free-for-all" mode may make it less important
>> to
>> solve exactly and elegantly. Retroactive weird modifications to a slow
>> client's canvas may be acceptable.
>>
>> Actually, after rereading what I just wrote, I think I'm missing the
>> point.
>> Consider the scenario of a distributed software development team
>> working on
>> a design spec using UML class diagrams. Each collaborator would
>> probably be
>> assigned to a different piece of the architecture. However, overlaps
>> are
>> bound to occur. Imagine keeping the chat session open for days or
>> weeks, as
>> developers log in to make changes. This scenario would be very useful.
>> However, in this case, we may not need to worry about slow clients
>> because
>> it is still not a completely realtime scenario...like fooling around
>> is.
>> Plus, this scenario would still have a core team responsible for
>> manually
>> resolving conflicts if they cannot be resolved algorithmically.
>>
>> What we do know, is that we can move forward with "pen" mode before
>> we come
>> to conclusions regarding "free-for-all" mode. But, let's keep the
>> discussion
>> open.
>>
>> One more thing, since I love analogies, "pen" mode is likened to
>> pessimistic
>> concurrency control, while "free-for-all" is likened to optimisitc ;)
>>
>> Anywho, that's all for now.
>>
>> Andy
>>
>> -----Original Message-----
>> From: con...@li...
>> [mailto:con...@li...]On Behalf Of
>> Scott
>> Luan
>> Sent: Sunday, August 03, 2003 11:31 PM
>> To: con...@li...
>> Subject: Re: [convey-developers] concurrency model
>>
>>
>> Hello all,
>>
>> I agree that the fundamental and distinct issues we face are:
>>
>> (1) non-sequential arrival of messages (We are assuming that a message
>> once transmitted is guarenteed to arrive at its destination.)
>>
>> (2) concurrency of canvas events
>>
>> Andy proposed a canvas-object locking mechanism which employs the chat
>> session initiator as a resolver or "host". This method addresses the
>> concurrency problem by permitting only one client to have
>> write-permission
>> to any object by requiring a handshake with the resolver client.
>>
>> However, I think the problem of the non-sequential arrival of
>> messages still
>> exists. For example, assuming client (R1) has received a lock-accept
>> message from client (I), and (R1) proceeds to make changes to an
>> object.
>> These changes are propagated to other occupants (R2,R3,...) in the
>> chat room
>> either by sending a message to all clients (ro...@ja...rver)
>> directly or
>> by having the message relayed by (I). There may be the possibility
>> that
>> messages for two modifications, f1(object), f2(object) are generated
>> by (R1)
>> in close temporal proximity and their arrival at (R2) are in reverse
>> order.
>> Since, f2(f1(object) != f1(f2(object)), the canvas of (R2) will be
>> different
>> from that of (R1).
>>
>> A realistic situation which may reveal this problem is when a user
>> makes
>> changes to a selected object by quick keystrokes (i.e.
>> [enter],[enter],...).
>> Due to network conditions, the first message is lost and
>> retransmitted but
>> the retransmission arrives after the second message.
>>
>> Another point of consideration in regards to Andy's proposal is this:
>> The
>> system of networked clients will be limited to the quality of the
>> connection
>> of the chat session initiator. Furthermore, it will be less a
>> "distributed"
>> system in which each client is autonomous (although not peer-to-peer
>> since a
>> Jabber server is involved). This may be relevant for concerns about
>> not
>> only performance but reliability. What if client (I) suddenly loses
>> network
>> connection?
>>
>> Is it possible to solve the concurrency problem without requiring a
>> "resolver"? Or to use different words: Is it possible to implement
>> an
>> object locking mechanism without a "resolver"?
>>
>> There are various aspects which are problematic with the following
>> idea (and
>> which I'll mention shortly) but let me revisit it. Consider the
>> possibility
>> of using timestamps for messages and a way to record a
>> history window of a canvas. Messages for each client are sent to
>> every
>> other client via a jabber chatroom broadcast. Each message
>> (representing a
>> canvas modification) are applied to a canvas by also considering its
>> timestamp -- a modification may be applied retroactively; precedence
>> in
>> time.
>>
>> Consider the situation in which (R1) makes a modification f1(object)
>> at t1
>> and (R2) making modification f2(object) at t2, where t1 < t2. At
>> some time
>> (t2 + e), (R1)'s canvas would be confronted with
>> f1(f2(object) and (R2)'s canvas with f2(f1(object). Each client
>> resolves
>> modifications for its own canvas by referring to the timestamps.
>> Since t1 <
>> t2, (R1) will simply apply f2. However, if f1(f2(obj) != f2(f1(obj),
>> then
>> (R2) will undo f2, apply f1, then f2.
>>
>> However, consider the situation in which f1 is incompatible with f2,
>> at some
>> time (t2 + e), (R1)'s canvas
>> would be confronted with f1(f2(object) and (R2)'s canvas with
>> f2(f1(object).
>> Given the incompatibility of f1 and f2, for (R1), f2 would be
>> ignored For
>> (R2), f2 would be undone and f1 applied, since t1 < t2.
>>
>> There are potential issues to this scheme.
>> (1) How do we accurately sync the timestamp? We may consider
>> including the
>> travel time of the timestamp packet itself.
>> (2) How do we deal with a mix of really slow and fast clients? The
>> conversation would result in wierd retrograde motions. This may
>> be
>> accounted for by setting the history window so that clients who
>> don't meet that requirement would not have their messages
>> recognized. However, this cut-off may result, perhaps in rare
>> instance, in asymmetries. Consider, the last example, with f2
>> reaching (R1) but f1 being cut-of by (R2).
>> (3) The history window, itself, may be problematic. How much would it
>> impact the memory usage and performance if we keep even a short (a
>> few seconds) archive of the document?
>>
>> Scott
>>
>>
>> >From: "Andy Ames" <ag...@sb...>
>> >Reply-To: con...@li...
>> >To: <con...@li...>
>> >Subject: [convey-developers] concurrency model
>> >Date: Sun, 3 Aug 2003 14:53:09 -0700
>> >
>> >Hey, guys.
>> >
>> >I thought I would send some of my thoughts regarding a concurrent
>> object
>> >model. That way, we can get primed for our design meetings. I've been
>> >poking
>> >around the Jabber spec (their calling it XMPP for eXtensible
>> Messaging and
>> >presence Protocol) and have learned some things.
>> >
>> >Basically, when sending an IM from one client to another, there is no
>> >guarantee regarding the order the messages arrive. This is inherent
>> in the
>> >IM paradigm. However, this creates a problem for our concurrent
>> object
>> >model, because we cannot ever make any guarantees regarding the
>> order of
>> >messages, even if we do a locking mechanism on object selection.
>> >
>> >The only solution I can think of is to filter all messages through
>> the
>> >"host" or initiator of the chat session. That way, all message order
>> and
>> >concurrent conflicts will be resolved by a single entity responsible
>> for
>> >resolving it.
>> >
>> >We did discuss this solution briefly. But, now I am more convinced
>> that
>> >this
>> >is our only option. So, I've outlined a couple scenarios.
>> >
>> >These scenarios are one-on-one chat scenarios. The initiator is
>> denoted by
>> >client 'I' and the receiver by client 'R'. Each scenario has some
>> example
>> >XML that I made up just for illustration purposes. These are rather
>> long,
>> >so
>> >you might want to take some time to digest them. There are exactly
>> two
>> >scenarios.
>> >
>> >1) Scenario 1
>> >
>> >a) Client I sends a "New Graphic" event for a rectangle to client R.
>> >
>> ><message to="R...@do.../Convey"
>> > from="I...@do.../Convey"
>> > subject="Hello, there!"
>> > thread="123456789">
>> > <new id="rect1">
>> > <rect x="10" y="20" width="100" height="200"/>
>> > </new>
>> ></message>
>> >
>> >Our Convey for Java automatically selects newly created objects. I
>> think
>> >for
>> >our concurrent model, we shouldn't do this automatically to be fair
>> to the
>> >other participants. For these scenarios, selecting an object puts a
>> lock on
>> >it.
>> >
>> >b) Client R receives the "New Graphic" event for the rectangle from
>> client
>> >I. Note that it isn't until this point that client R becomes aware of
>> >client
>> >I.
>> >
>> >At this point, neither Client I nor R has a lock on the newly created
>> >Graphic. Suppose, then, that Client R attempts to select the
>> rectangle.
>> >This
>> >sends a lock request message to client I.
>> >
>> ><message to="I...@do.../Convey"
>> > from="R...@do.../Convey"
>> > thread="123456789">
>> > <lock-request id="rect1"/>
>> ></message>
>> >
>> >c) Client I receives the lock request, and replies with success.
>> >
>> ><message to="R...@do.../Convey"
>> > from="I...@do.../Convey"
>> > thread="123456789">
>> > <lock-accept id="rect1"/>
>> ></message>
>> >
>> >d) Client R receives the lock-accept message, and highlights the
>> rectangle
>> >with green border. Until now, client R would not be able to
>> manipulate the
>> >rectangle.
>> >
>> >Client R moves the rectangle.
>> >
>> ><message to="I...@do.../Convey"
>> > from="R...@do.../Convey"
>> > thread="123456789">
>> > <translate id="rect1" x="20" y="30"/>
>> ></message>
>> >
>> >e) Client I receives the translation event. Let's say client I now
>> attempts
>> >to select the rectangle. Client I simply checks its local copy of
>> the DOM
>> >tree to see if there is already a lock on the graphic. In this case,
>> there
>> >is, so the rectangle is drawn with a red border.
>> >
>> >f) Client R deselects the rectangle. This notifies client I that the
>> lock
>> >should be released.
>> >
>> ><message to="I...@do.../Convey"
>> > from="R...@do.../Convey"
>> > thread="123456789">
>> > <lock-release id="rect1"/>
>> ></message>
>> >
>> >g) Client I receives the lock release message. The rectangle's
>> border now
>> >turns green for client I, because it was selected. Now, client I has
>> the
>> >lock.
>> >
>> >2) Scenario 2
>> >
>> >a) Client I sends a "New Graphic" event for a rectangle to client R.
>> >
>> ><message to="R...@do.../Convey"
>> > from="I...@do.../Convey"
>> > subject="Hello, there!"
>> > thread="123456789">
>> > <new id="rect1">
>> > <rect x="10" y="20" width="100" height="200"/>
>> > </new>
>> ></message>
>> >
>> >b) Client R receives the "New Graphic" event for the rectangle from
>> client
>> >I.
>> >
>> >c) Client I selects the rectangle. Since client I has the object
>> model, it
>> >is checked to see if there is already a lock on it. There isn't, so
>> client
>> >I
>> >has the lock and the rectangle is drawn with a green border for
>> client I.
>> >
>> >Client I moves the rectangle.
>> >
>> ><message to="R...@do.../Convey"
>> > from="I...@do.../Convey"
>> > subject="Hello, there!"
>> > thread="123456789">
>> > <translate id="rect1" x="20" y="30"/>
>> ></message>
>> >
>> >d) Client R receives the translation event. Client R attempts to
>> select the
>> >rectangle. This sends a lock request message to client I.
>> >
>> ><message to="I...@do.../Convey"
>> > from="R...@do.../Convey"
>> > thread="123456789">
>> > <lock-request id="rect1"/>
>> ></message>
>> >
>> >e) Client I receives the lock request, but rejects it because client
>> I has
>> >the lock.
>> >
>> ><message to="R...@do.../Convey"
>> > from="I...@do.../Convey"
>> > thread="123456789">
>> > <lock-reject id="rect1"/>
>> ></message>
>> >
>> >f) Client R receives the lock rejection and paints the rectangle
>> border
>> >red.
>> >
>> >g) Client I deselects the rectangle. This sends a lock accept
>> message to
>> >client R, because client R had requested the lock previously.
>> >
>> ><message to="R...@do.../Convey"
>> > from="I...@do.../Convey"
>> > thread="123456789">
>> > <lock-accept id="rect1"/>
>> ></message>
>> >
>> >h) Client R receives the lock accept message. The rectangle's border
>> turns
>> >green and client R has the lock.
>> >
>> >An alternative path for {f} and (g) might be...
>> >
>> >f) (alt) Client R receives the lock rejection and paints the
>> rectangle
>> >border red. Then, client R deselects the rectangle. This sends a lock
>> >release message to client I, indicating that client R no longer
>> wishes to
>> >lock the rectangle.
>> >
>> ><message to="R...@do.../Convey"
>> > from="I...@do.../Convey"
>> > thread="123456789">
>> > <lock-release id="rect1"/>
>> ></message>
>> >
>> >g) (alt) Client I receives the lock release message. Client I now
>> deselects
>> >the rectangle. Because client R is no longer waiting for the lock,
>> no lock
>> >accept message is sent to client R.
>> >
>> >Have fun with it. If you have any other scenarios, feel free to add
>> them.
>> >
>> >Andy
>> >
>> >
>> >
>> >-------------------------------------------------------
>> >This SF.Net email sponsored by: Free pre-built ASP.NET sites
>> including
>> >Data Reports, E-commerce, Portals, and Forums are available now.
>> >Download today and enter to win an XBOX or Visual Studio .NET.
>> >http://aspnet.click-url.com/go/psa00100003ave/
>> direct;at.aspnet_072303_01/01
>> >_______________________________________________
>> >convey-developers mailing list
>> >con...@li...
>> >https://lists.sourceforge.net/lists/listinfo/convey-developers
>>
>> _________________________________________________________________
>> STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
>> http://join.msn.com/?page=features/junkmail
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> Data Reports, E-commerce, Portals, and Forums are available now.
>> Download today and enter to win an XBOX or Visual Studio .NET.
>> http://aspnet.click-url.com/go/psa00100003ave/
>> direct;at.aspnet_072303_01/01
>> _______________________________________________
>> convey-developers mailing list
>> con...@li...
>> https://lists.sourceforge.net/lists/listinfo/convey-developers
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> Data Reports, E-commerce, Portals, and Forums are available now.
>> Download today and enter to win an XBOX or Visual Studio .NET.
>> http://aspnet.click-url.com/go/psa00100003ave/
>> direct;at.aspnet_072303_01/01
>> _______________________________________________
>> convey-developers mailing list
>> con...@li...
>> https://lists.sourceforge.net/lists/listinfo/convey-developers
>
> _________________________________________________________________
> Protect your PC - get McAfee.com VirusScan Online
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/
> direct;at.aspnet_072303_01/01
> _______________________________________________
> convey-developers mailing list
> con...@li...
> https://lists.sourceforge.net/lists/listinfo/convey-developers
>
|
|
From: Scott L. <sco...@ho...> - 2003-08-05 05:53:15
|
You can count me in. >From: "Andy Ames" <ag...@sb...> >Reply-To: con...@li... >To: <con...@li...> >Subject: [convey-developers] wxjab module via wxxml >Date: Mon, 4 Aug 2003 02:07:42 -0700 > >First jabber message using wxjab! > >I added the wxjab module to our repository. It uses the wxXml module to >stream XML in and out of a socket connection. > >The API is very basic at this point. But you can login (with a plain text >password) and send messages across the jabber network. > >Next, support for digest authentication using SHA and the ability to >receive >and parse incoming messages. > >Anyway, we're really close (about 5 days) from having a working jabber API >in C++. I have to admit, though, that wxjab and wxxml are probably a bit >buggy, their lacking robust error handling, and only support the US-ASCII >subset of UTF-8. > >I'd like to know if either of you would like to volunteer to maintain the >wxxml module. We can work on it together, but I'd like someone to be >responsible for seeing that the desired improvements actually happen. Even >if this means I get assigned to 95% of the code changes, that's fine. I'm >throwing 20 hours a week at Convey currently, so that would not be a >problem. I would rather not have to do the management of the changes, so I >can charge ahead with wxjab. > >What this role means, is the person would learn the ins and outs of XML in >general. They would become familiar with the XML spec so they can reference >it when necessary. Then, this person would decide, based on inputs from the >others, what features are important to put into the wxxml module. This >person would pour over the bugs and feature requests regarding wxxml and >filter them as necessary. > >G'night. > >Andy > > > >------------------------------------------------------- >This SF.Net email sponsored by: Free pre-built ASP.NET sites including >Data Reports, E-commerce, Portals, and Forums are available now. >Download today and enter to win an XBOX or Visual Studio .NET. >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 >_______________________________________________ >convey-developers mailing list >con...@li... >https://lists.sourceforge.net/lists/listinfo/convey-developers _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail |
|
From: Scott L. <sco...@ho...> - 2003-08-05 05:47:55
|
Hi Andy,
Thanks for your response. :-)
I think that the two options discussed earlier relate to more than a
"pen"-vs-"free-for-all" distinction. What I was trying to get at in my
earlier emails (and which I can't find on the developers' discussion board),
and perhaps didn't make clear, is that the kind of transactional scheme (how
clients' canvases get updated) may ultimately relate to the reuseability of
the Convey technology. Specifically, it may be really nice if the Jabber
messages are not in the form of SVG or Convey specs; communicating in the
generic format of XML doc diffs may have some problematic aspects, but I
think it would be a worthwhile endeavor since this mode of communiation may
apply to all kinds of XML representations.
Therefore, also directly relevant is how Convey would be extended for other
kinds of canvas markings. The XML-diff method, I believe, not only tries to
address the problems of concurrency and non-sequential messages but also
concerns about reuseability. Perhaps this is getting ahead of ourselves,
but, yes, let's keep the discussion open. :-)
About that timestamp ... what I had in mind is that each client would keep a
running time-count which is sync'ed only once when it connects to a
chatroom. All messages sent by this client would be timestamped before it
reaches the Jabber server. The time sync may be coordinated with the
chatroom initiator, the Jabber server, or some reliable machine on the
internet. The problem which I believe we need to address is how to
eliminate resulting biases caused by different client connection speeds --
how to compensate for the time-sync packet travel time may involve digging
into the packet for the appropriate data.
Scott
>From: "Andy Ames" <ag...@sb...>
>Reply-To: con...@li...
>To: <con...@li...>
>Subject: RE: [convey-developers] concurrency model
>Date: Mon, 4 Aug 2003 12:25:49 -0700
>
>Scott,
>
>Thank you for the thorough reply. Your descriptions of the problem are easy
>to read and follow.
>
>Your description of resolving conflicts retroactively based on a timestamp
>parallels the diff, patch, and cvs programs. We could probably base our
>solutions on the ideologies of these programs.
>
>A diff file is analogous to our Graphic event. In a diff file, you can have
>lines added, changed, or removed. A New Graphic event is lines added, a
>Delete Graphic event is lines removed, and a Graphic Change event is lines
>changed.
>
>A diff may be applied to a file using the patch command. This command can
>take timestamps into account when applying multiple patches.
>
>Some other issues we'd need to solve with this scenario:
>
>1) Who generates the timestamps? The jabber protocol does have an extension
>(that I believe is well-supported) for producing timestamps using GMT.
>Also,
>with our diff/patch analogy, the patches are intended to be sent out from
>the core team. Generally, when many developers are making changes and
>submitting patches, there needs to be a "resolver" of conflicts. This
>implies that we still would need a client to act as "resolver."
>
>Or might I be wrong with this assumption. I guess we'd need to look at the
>Jabber spec regarding timestamps. If the timestamp is guarenteed to be
>generated by the same host for all messages in a chat session or one-on-one
>session, then each client can be the resolver on its own. If this is the
>case, it leads to the next issue (which I believe you touched on).
>
>2) When a client (R1) (presumably faster than the rest) sends a message
>f1(object) at time t1 and another client (R2) (presumably slower) sends a
>message f2(object) at time t2, where t1 < t2, then client (R2) doesn't even
>know what the timestamp, t2 is of the message that it sent! Client (R2)
>would need to be notified by the host of the timestamp, t2, its message was
>given, so that (R2) can resolve all further incoming messages, such as
>f1(object).
>
>To give us some context, I'd like to point out that what we are trying to
>solve here, is how to do a "free-for-all" collaboration session. We coined
>this term a while ago and differentiated it from a "moderated"
>collaboration
>session. The latter is controlled by the "pen" concept. Whoever has the
>"pen" can modify the canvas. No one else can until they have the pen. The
>pen is controlled by the session host or initiator.
>
>The "pen" may also be controlled algorithmically in some situations such as
>turn-based board games and RPGs.
>
>The "pen" solution is useful for moderated discusssions such as tutoring
>and
>other formal collaboration. It seems the "free-for-all" mode is really
>useful just for fooling around. It may be too problematic to be practical.
>
>The foreseeable use of "free-for-all" mode may make it less important to
>solve exactly and elegantly. Retroactive weird modifications to a slow
>client's canvas may be acceptable.
>
>Actually, after rereading what I just wrote, I think I'm missing the point.
>Consider the scenario of a distributed software development team working on
>a design spec using UML class diagrams. Each collaborator would probably be
>assigned to a different piece of the architecture. However, overlaps are
>bound to occur. Imagine keeping the chat session open for days or weeks, as
>developers log in to make changes. This scenario would be very useful.
>However, in this case, we may not need to worry about slow clients because
>it is still not a completely realtime scenario...like fooling around is.
>Plus, this scenario would still have a core team responsible for manually
>resolving conflicts if they cannot be resolved algorithmically.
>
>What we do know, is that we can move forward with "pen" mode before we come
>to conclusions regarding "free-for-all" mode. But, let's keep the
>discussion
>open.
>
>One more thing, since I love analogies, "pen" mode is likened to
>pessimistic
>concurrency control, while "free-for-all" is likened to optimisitc ;)
>
>Anywho, that's all for now.
>
>Andy
>
>-----Original Message-----
>From: con...@li...
>[mailto:con...@li...]On Behalf Of Scott
>Luan
>Sent: Sunday, August 03, 2003 11:31 PM
>To: con...@li...
>Subject: Re: [convey-developers] concurrency model
>
>
>Hello all,
>
>I agree that the fundamental and distinct issues we face are:
>
>(1) non-sequential arrival of messages (We are assuming that a message
> once transmitted is guarenteed to arrive at its destination.)
>
>(2) concurrency of canvas events
>
>Andy proposed a canvas-object locking mechanism which employs the chat
>session initiator as a resolver or "host". This method addresses the
>concurrency problem by permitting only one client to have write-permission
>to any object by requiring a handshake with the resolver client.
>
>However, I think the problem of the non-sequential arrival of messages
>still
>exists. For example, assuming client (R1) has received a lock-accept
>message from client (I), and (R1) proceeds to make changes to an object.
>These changes are propagated to other occupants (R2,R3,...) in the chat
>room
>either by sending a message to all clients (ro...@ja...rver) directly or
>by having the message relayed by (I). There may be the possibility that
>messages for two modifications, f1(object), f2(object) are generated by
>(R1)
>in close temporal proximity and their arrival at (R2) are in reverse order.
>Since, f2(f1(object) != f1(f2(object)), the canvas of (R2) will be
>different
>from that of (R1).
>
>A realistic situation which may reveal this problem is when a user makes
>changes to a selected object by quick keystrokes (i.e.
>[enter],[enter],...).
>Due to network conditions, the first message is lost and retransmitted but
>the retransmission arrives after the second message.
>
>Another point of consideration in regards to Andy's proposal is this: The
>system of networked clients will be limited to the quality of the
>connection
>of the chat session initiator. Furthermore, it will be less a
>"distributed"
>system in which each client is autonomous (although not peer-to-peer since
>a
>Jabber server is involved). This may be relevant for concerns about not
>only performance but reliability. What if client (I) suddenly loses network
>connection?
>
>Is it possible to solve the concurrency problem without requiring a
>"resolver"? Or to use different words: Is it possible to implement an
>object locking mechanism without a "resolver"?
>
>There are various aspects which are problematic with the following idea
>(and
>which I'll mention shortly) but let me revisit it. Consider the
>possibility
>of using timestamps for messages and a way to record a
>history window of a canvas. Messages for each client are sent to every
>other client via a jabber chatroom broadcast. Each message (representing a
>canvas modification) are applied to a canvas by also considering its
>timestamp -- a modification may be applied retroactively; precedence in
>time.
>
>Consider the situation in which (R1) makes a modification f1(object) at t1
>and (R2) making modification f2(object) at t2, where t1 < t2. At some
>time
>(t2 + e), (R1)'s canvas would be confronted with
>f1(f2(object) and (R2)'s canvas with f2(f1(object). Each client resolves
>modifications for its own canvas by referring to the timestamps. Since t1
><
>t2, (R1) will simply apply f2. However, if f1(f2(obj) != f2(f1(obj), then
>(R2) will undo f2, apply f1, then f2.
>
>However, consider the situation in which f1 is incompatible with f2, at
>some
>time (t2 + e), (R1)'s canvas
>would be confronted with f1(f2(object) and (R2)'s canvas with
>f2(f1(object).
> Given the incompatibility of f1 and f2, for (R1), f2 would be ignored
>For
>(R2), f2 would be undone and f1 applied, since t1 < t2.
>
>There are potential issues to this scheme.
>(1) How do we accurately sync the timestamp? We may consider including the
> travel time of the timestamp packet itself.
>(2) How do we deal with a mix of really slow and fast clients? The
> conversation would result in wierd retrograde motions. This may be
> accounted for by setting the history window so that clients who
> don't meet that requirement would not have their messages
> recognized. However, this cut-off may result, perhaps in rare
> instance, in asymmetries. Consider, the last example, with f2
> reaching (R1) but f1 being cut-of by (R2).
>(3) The history window, itself, may be problematic. How much would it
> impact the memory usage and performance if we keep even a short (a
> few seconds) archive of the document?
>
>Scott
>
>
> >From: "Andy Ames" <ag...@sb...>
> >Reply-To: con...@li...
> >To: <con...@li...>
> >Subject: [convey-developers] concurrency model
> >Date: Sun, 3 Aug 2003 14:53:09 -0700
> >
> >Hey, guys.
> >
> >I thought I would send some of my thoughts regarding a concurrent object
> >model. That way, we can get primed for our design meetings. I've been
> >poking
> >around the Jabber spec (their calling it XMPP for eXtensible Messaging
>and
> >presence Protocol) and have learned some things.
> >
> >Basically, when sending an IM from one client to another, there is no
> >guarantee regarding the order the messages arrive. This is inherent in
>the
> >IM paradigm. However, this creates a problem for our concurrent object
> >model, because we cannot ever make any guarantees regarding the order of
> >messages, even if we do a locking mechanism on object selection.
> >
> >The only solution I can think of is to filter all messages through the
> >"host" or initiator of the chat session. That way, all message order and
> >concurrent conflicts will be resolved by a single entity responsible for
> >resolving it.
> >
> >We did discuss this solution briefly. But, now I am more convinced that
> >this
> >is our only option. So, I've outlined a couple scenarios.
> >
> >These scenarios are one-on-one chat scenarios. The initiator is denoted
>by
> >client 'I' and the receiver by client 'R'. Each scenario has some example
> >XML that I made up just for illustration purposes. These are rather long,
> >so
> >you might want to take some time to digest them. There are exactly two
> >scenarios.
> >
> >1) Scenario 1
> >
> >a) Client I sends a "New Graphic" event for a rectangle to client R.
> >
> ><message to="R...@do.../Convey"
> > from="I...@do.../Convey"
> > subject="Hello, there!"
> > thread="123456789">
> > <new id="rect1">
> > <rect x="10" y="20" width="100" height="200"/>
> > </new>
> ></message>
> >
> >Our Convey for Java automatically selects newly created objects. I think
> >for
> >our concurrent model, we shouldn't do this automatically to be fair to
>the
> >other participants. For these scenarios, selecting an object puts a lock
>on
> >it.
> >
> >b) Client R receives the "New Graphic" event for the rectangle from
>client
> >I. Note that it isn't until this point that client R becomes aware of
> >client
> >I.
> >
> >At this point, neither Client I nor R has a lock on the newly created
> >Graphic. Suppose, then, that Client R attempts to select the rectangle.
> >This
> >sends a lock request message to client I.
> >
> ><message to="I...@do.../Convey"
> > from="R...@do.../Convey"
> > thread="123456789">
> > <lock-request id="rect1"/>
> ></message>
> >
> >c) Client I receives the lock request, and replies with success.
> >
> ><message to="R...@do.../Convey"
> > from="I...@do.../Convey"
> > thread="123456789">
> > <lock-accept id="rect1"/>
> ></message>
> >
> >d) Client R receives the lock-accept message, and highlights the
>rectangle
> >with green border. Until now, client R would not be able to manipulate
>the
> >rectangle.
> >
> >Client R moves the rectangle.
> >
> ><message to="I...@do.../Convey"
> > from="R...@do.../Convey"
> > thread="123456789">
> > <translate id="rect1" x="20" y="30"/>
> ></message>
> >
> >e) Client I receives the translation event. Let's say client I now
>attempts
> >to select the rectangle. Client I simply checks its local copy of the DOM
> >tree to see if there is already a lock on the graphic. In this case,
>there
> >is, so the rectangle is drawn with a red border.
> >
> >f) Client R deselects the rectangle. This notifies client I that the lock
> >should be released.
> >
> ><message to="I...@do.../Convey"
> > from="R...@do.../Convey"
> > thread="123456789">
> > <lock-release id="rect1"/>
> ></message>
> >
> >g) Client I receives the lock release message. The rectangle's border now
> >turns green for client I, because it was selected. Now, client I has the
> >lock.
> >
> >2) Scenario 2
> >
> >a) Client I sends a "New Graphic" event for a rectangle to client R.
> >
> ><message to="R...@do.../Convey"
> > from="I...@do.../Convey"
> > subject="Hello, there!"
> > thread="123456789">
> > <new id="rect1">
> > <rect x="10" y="20" width="100" height="200"/>
> > </new>
> ></message>
> >
> >b) Client R receives the "New Graphic" event for the rectangle from
>client
> >I.
> >
> >c) Client I selects the rectangle. Since client I has the object model,
>it
> >is checked to see if there is already a lock on it. There isn't, so
>client
> >I
> >has the lock and the rectangle is drawn with a green border for client I.
> >
> >Client I moves the rectangle.
> >
> ><message to="R...@do.../Convey"
> > from="I...@do.../Convey"
> > subject="Hello, there!"
> > thread="123456789">
> > <translate id="rect1" x="20" y="30"/>
> ></message>
> >
> >d) Client R receives the translation event. Client R attempts to select
>the
> >rectangle. This sends a lock request message to client I.
> >
> ><message to="I...@do.../Convey"
> > from="R...@do.../Convey"
> > thread="123456789">
> > <lock-request id="rect1"/>
> ></message>
> >
> >e) Client I receives the lock request, but rejects it because client I
>has
> >the lock.
> >
> ><message to="R...@do.../Convey"
> > from="I...@do.../Convey"
> > thread="123456789">
> > <lock-reject id="rect1"/>
> ></message>
> >
> >f) Client R receives the lock rejection and paints the rectangle border
> >red.
> >
> >g) Client I deselects the rectangle. This sends a lock accept message to
> >client R, because client R had requested the lock previously.
> >
> ><message to="R...@do.../Convey"
> > from="I...@do.../Convey"
> > thread="123456789">
> > <lock-accept id="rect1"/>
> ></message>
> >
> >h) Client R receives the lock accept message. The rectangle's border
>turns
> >green and client R has the lock.
> >
> >An alternative path for {f} and (g) might be...
> >
> >f) (alt) Client R receives the lock rejection and paints the rectangle
> >border red. Then, client R deselects the rectangle. This sends a lock
> >release message to client I, indicating that client R no longer wishes to
> >lock the rectangle.
> >
> ><message to="R...@do.../Convey"
> > from="I...@do.../Convey"
> > thread="123456789">
> > <lock-release id="rect1"/>
> ></message>
> >
> >g) (alt) Client I receives the lock release message. Client I now
>deselects
> >the rectangle. Because client R is no longer waiting for the lock, no
>lock
> >accept message is sent to client R.
> >
> >Have fun with it. If you have any other scenarios, feel free to add them.
> >
> >Andy
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> >Data Reports, E-commerce, Portals, and Forums are available now.
> >Download today and enter to win an XBOX or Visual Studio .NET.
> >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> >_______________________________________________
> >convey-developers mailing list
> >con...@li...
> >https://lists.sourceforge.net/lists/listinfo/convey-developers
>
>_________________________________________________________________
>STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
>http://join.msn.com/?page=features/junkmail
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>convey-developers mailing list
>con...@li...
>https://lists.sourceforge.net/lists/listinfo/convey-developers
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>convey-developers mailing list
>con...@li...
>https://lists.sourceforge.net/lists/listinfo/convey-developers
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
|
|
From: Andy A. <ag...@sb...> - 2003-08-04 19:25:58
|
Scott,
Thank you for the thorough reply. Your descriptions of the problem are easy
to read and follow.
Your description of resolving conflicts retroactively based on a timestamp
parallels the diff, patch, and cvs programs. We could probably base our
solutions on the ideologies of these programs.
A diff file is analogous to our Graphic event. In a diff file, you can have
lines added, changed, or removed. A New Graphic event is lines added, a
Delete Graphic event is lines removed, and a Graphic Change event is lines
changed.
A diff may be applied to a file using the patch command. This command can
take timestamps into account when applying multiple patches.
Some other issues we'd need to solve with this scenario:
1) Who generates the timestamps? The jabber protocol does have an extension
(that I believe is well-supported) for producing timestamps using GMT. Also,
with our diff/patch analogy, the patches are intended to be sent out from
the core team. Generally, when many developers are making changes and
submitting patches, there needs to be a "resolver" of conflicts. This
implies that we still would need a client to act as "resolver."
Or might I be wrong with this assumption. I guess we'd need to look at the
Jabber spec regarding timestamps. If the timestamp is guarenteed to be
generated by the same host for all messages in a chat session or one-on-one
session, then each client can be the resolver on its own. If this is the
case, it leads to the next issue (which I believe you touched on).
2) When a client (R1) (presumably faster than the rest) sends a message
f1(object) at time t1 and another client (R2) (presumably slower) sends a
message f2(object) at time t2, where t1 < t2, then client (R2) doesn't even
know what the timestamp, t2 is of the message that it sent! Client (R2)
would need to be notified by the host of the timestamp, t2, its message was
given, so that (R2) can resolve all further incoming messages, such as
f1(object).
To give us some context, I'd like to point out that what we are trying to
solve here, is how to do a "free-for-all" collaboration session. We coined
this term a while ago and differentiated it from a "moderated" collaboration
session. The latter is controlled by the "pen" concept. Whoever has the
"pen" can modify the canvas. No one else can until they have the pen. The
pen is controlled by the session host or initiator.
The "pen" may also be controlled algorithmically in some situations such as
turn-based board games and RPGs.
The "pen" solution is useful for moderated discusssions such as tutoring and
other formal collaboration. It seems the "free-for-all" mode is really
useful just for fooling around. It may be too problematic to be practical.
The foreseeable use of "free-for-all" mode may make it less important to
solve exactly and elegantly. Retroactive weird modifications to a slow
client's canvas may be acceptable.
Actually, after rereading what I just wrote, I think I'm missing the point.
Consider the scenario of a distributed software development team working on
a design spec using UML class diagrams. Each collaborator would probably be
assigned to a different piece of the architecture. However, overlaps are
bound to occur. Imagine keeping the chat session open for days or weeks, as
developers log in to make changes. This scenario would be very useful.
However, in this case, we may not need to worry about slow clients because
it is still not a completely realtime scenario...like fooling around is.
Plus, this scenario would still have a core team responsible for manually
resolving conflicts if they cannot be resolved algorithmically.
What we do know, is that we can move forward with "pen" mode before we come
to conclusions regarding "free-for-all" mode. But, let's keep the discussion
open.
One more thing, since I love analogies, "pen" mode is likened to pessimistic
concurrency control, while "free-for-all" is likened to optimisitc ;)
Anywho, that's all for now.
Andy
-----Original Message-----
From: con...@li...
[mailto:con...@li...]On Behalf Of Scott
Luan
Sent: Sunday, August 03, 2003 11:31 PM
To: con...@li...
Subject: Re: [convey-developers] concurrency model
Hello all,
I agree that the fundamental and distinct issues we face are:
(1) non-sequential arrival of messages (We are assuming that a message
once transmitted is guarenteed to arrive at its destination.)
(2) concurrency of canvas events
Andy proposed a canvas-object locking mechanism which employs the chat
session initiator as a resolver or "host". This method addresses the
concurrency problem by permitting only one client to have write-permission
to any object by requiring a handshake with the resolver client.
However, I think the problem of the non-sequential arrival of messages still
exists. For example, assuming client (R1) has received a lock-accept
message from client (I), and (R1) proceeds to make changes to an object.
These changes are propagated to other occupants (R2,R3,...) in the chat room
either by sending a message to all clients (ro...@ja...rver) directly or
by having the message relayed by (I). There may be the possibility that
messages for two modifications, f1(object), f2(object) are generated by (R1)
in close temporal proximity and their arrival at (R2) are in reverse order.
Since, f2(f1(object) != f1(f2(object)), the canvas of (R2) will be different
from that of (R1).
A realistic situation which may reveal this problem is when a user makes
changes to a selected object by quick keystrokes (i.e. [enter],[enter],...).
Due to network conditions, the first message is lost and retransmitted but
the retransmission arrives after the second message.
Another point of consideration in regards to Andy's proposal is this: The
system of networked clients will be limited to the quality of the connection
of the chat session initiator. Furthermore, it will be less a "distributed"
system in which each client is autonomous (although not peer-to-peer since a
Jabber server is involved). This may be relevant for concerns about not
only performance but reliability. What if client (I) suddenly loses network
connection?
Is it possible to solve the concurrency problem without requiring a
"resolver"? Or to use different words: Is it possible to implement an
object locking mechanism without a "resolver"?
There are various aspects which are problematic with the following idea (and
which I'll mention shortly) but let me revisit it. Consider the possibility
of using timestamps for messages and a way to record a
history window of a canvas. Messages for each client are sent to every
other client via a jabber chatroom broadcast. Each message (representing a
canvas modification) are applied to a canvas by also considering its
timestamp -- a modification may be applied retroactively; precedence in
time.
Consider the situation in which (R1) makes a modification f1(object) at t1
and (R2) making modification f2(object) at t2, where t1 < t2. At some time
(t2 + e), (R1)'s canvas would be confronted with
f1(f2(object) and (R2)'s canvas with f2(f1(object). Each client resolves
modifications for its own canvas by referring to the timestamps. Since t1 <
t2, (R1) will simply apply f2. However, if f1(f2(obj) != f2(f1(obj), then
(R2) will undo f2, apply f1, then f2.
However, consider the situation in which f1 is incompatible with f2, at some
time (t2 + e), (R1)'s canvas
would be confronted with f1(f2(object) and (R2)'s canvas with f2(f1(object).
Given the incompatibility of f1 and f2, for (R1), f2 would be ignored For
(R2), f2 would be undone and f1 applied, since t1 < t2.
There are potential issues to this scheme.
(1) How do we accurately sync the timestamp? We may consider including the
travel time of the timestamp packet itself.
(2) How do we deal with a mix of really slow and fast clients? The
conversation would result in wierd retrograde motions. This may be
accounted for by setting the history window so that clients who
don't meet that requirement would not have their messages
recognized. However, this cut-off may result, perhaps in rare
instance, in asymmetries. Consider, the last example, with f2
reaching (R1) but f1 being cut-of by (R2).
(3) The history window, itself, may be problematic. How much would it
impact the memory usage and performance if we keep even a short (a
few seconds) archive of the document?
Scott
>From: "Andy Ames" <ag...@sb...>
>Reply-To: con...@li...
>To: <con...@li...>
>Subject: [convey-developers] concurrency model
>Date: Sun, 3 Aug 2003 14:53:09 -0700
>
>Hey, guys.
>
>I thought I would send some of my thoughts regarding a concurrent object
>model. That way, we can get primed for our design meetings. I've been
>poking
>around the Jabber spec (their calling it XMPP for eXtensible Messaging and
>presence Protocol) and have learned some things.
>
>Basically, when sending an IM from one client to another, there is no
>guarantee regarding the order the messages arrive. This is inherent in the
>IM paradigm. However, this creates a problem for our concurrent object
>model, because we cannot ever make any guarantees regarding the order of
>messages, even if we do a locking mechanism on object selection.
>
>The only solution I can think of is to filter all messages through the
>"host" or initiator of the chat session. That way, all message order and
>concurrent conflicts will be resolved by a single entity responsible for
>resolving it.
>
>We did discuss this solution briefly. But, now I am more convinced that
>this
>is our only option. So, I've outlined a couple scenarios.
>
>These scenarios are one-on-one chat scenarios. The initiator is denoted by
>client 'I' and the receiver by client 'R'. Each scenario has some example
>XML that I made up just for illustration purposes. These are rather long,
>so
>you might want to take some time to digest them. There are exactly two
>scenarios.
>
>1) Scenario 1
>
>a) Client I sends a "New Graphic" event for a rectangle to client R.
>
><message to="R...@do.../Convey"
> from="I...@do.../Convey"
> subject="Hello, there!"
> thread="123456789">
> <new id="rect1">
> <rect x="10" y="20" width="100" height="200"/>
> </new>
></message>
>
>Our Convey for Java automatically selects newly created objects. I think
>for
>our concurrent model, we shouldn't do this automatically to be fair to the
>other participants. For these scenarios, selecting an object puts a lock on
>it.
>
>b) Client R receives the "New Graphic" event for the rectangle from client
>I. Note that it isn't until this point that client R becomes aware of
>client
>I.
>
>At this point, neither Client I nor R has a lock on the newly created
>Graphic. Suppose, then, that Client R attempts to select the rectangle.
>This
>sends a lock request message to client I.
>
><message to="I...@do.../Convey"
> from="R...@do.../Convey"
> thread="123456789">
> <lock-request id="rect1"/>
></message>
>
>c) Client I receives the lock request, and replies with success.
>
><message to="R...@do.../Convey"
> from="I...@do.../Convey"
> thread="123456789">
> <lock-accept id="rect1"/>
></message>
>
>d) Client R receives the lock-accept message, and highlights the rectangle
>with green border. Until now, client R would not be able to manipulate the
>rectangle.
>
>Client R moves the rectangle.
>
><message to="I...@do.../Convey"
> from="R...@do.../Convey"
> thread="123456789">
> <translate id="rect1" x="20" y="30"/>
></message>
>
>e) Client I receives the translation event. Let's say client I now attempts
>to select the rectangle. Client I simply checks its local copy of the DOM
>tree to see if there is already a lock on the graphic. In this case, there
>is, so the rectangle is drawn with a red border.
>
>f) Client R deselects the rectangle. This notifies client I that the lock
>should be released.
>
><message to="I...@do.../Convey"
> from="R...@do.../Convey"
> thread="123456789">
> <lock-release id="rect1"/>
></message>
>
>g) Client I receives the lock release message. The rectangle's border now
>turns green for client I, because it was selected. Now, client I has the
>lock.
>
>2) Scenario 2
>
>a) Client I sends a "New Graphic" event for a rectangle to client R.
>
><message to="R...@do.../Convey"
> from="I...@do.../Convey"
> subject="Hello, there!"
> thread="123456789">
> <new id="rect1">
> <rect x="10" y="20" width="100" height="200"/>
> </new>
></message>
>
>b) Client R receives the "New Graphic" event for the rectangle from client
>I.
>
>c) Client I selects the rectangle. Since client I has the object model, it
>is checked to see if there is already a lock on it. There isn't, so client
>I
>has the lock and the rectangle is drawn with a green border for client I.
>
>Client I moves the rectangle.
>
><message to="R...@do.../Convey"
> from="I...@do.../Convey"
> subject="Hello, there!"
> thread="123456789">
> <translate id="rect1" x="20" y="30"/>
></message>
>
>d) Client R receives the translation event. Client R attempts to select the
>rectangle. This sends a lock request message to client I.
>
><message to="I...@do.../Convey"
> from="R...@do.../Convey"
> thread="123456789">
> <lock-request id="rect1"/>
></message>
>
>e) Client I receives the lock request, but rejects it because client I has
>the lock.
>
><message to="R...@do.../Convey"
> from="I...@do.../Convey"
> thread="123456789">
> <lock-reject id="rect1"/>
></message>
>
>f) Client R receives the lock rejection and paints the rectangle border
>red.
>
>g) Client I deselects the rectangle. This sends a lock accept message to
>client R, because client R had requested the lock previously.
>
><message to="R...@do.../Convey"
> from="I...@do.../Convey"
> thread="123456789">
> <lock-accept id="rect1"/>
></message>
>
>h) Client R receives the lock accept message. The rectangle's border turns
>green and client R has the lock.
>
>An alternative path for {f} and (g) might be...
>
>f) (alt) Client R receives the lock rejection and paints the rectangle
>border red. Then, client R deselects the rectangle. This sends a lock
>release message to client I, indicating that client R no longer wishes to
>lock the rectangle.
>
><message to="R...@do.../Convey"
> from="I...@do.../Convey"
> thread="123456789">
> <lock-release id="rect1"/>
></message>
>
>g) (alt) Client I receives the lock release message. Client I now deselects
>the rectangle. Because client R is no longer waiting for the lock, no lock
>accept message is sent to client R.
>
>Have fun with it. If you have any other scenarios, feel free to add them.
>
>Andy
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>convey-developers mailing list
>con...@li...
>https://lists.sourceforge.net/lists/listinfo/convey-developers
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
convey-developers mailing list
con...@li...
https://lists.sourceforge.net/lists/listinfo/convey-developers
|
|
From: Andy A. <ag...@sb...> - 2003-08-04 09:07:30
|
First jabber message using wxjab! I added the wxjab module to our repository. It uses the wxXml module to stream XML in and out of a socket connection. The API is very basic at this point. But you can login (with a plain text password) and send messages across the jabber network. Next, support for digest authentication using SHA and the ability to receive and parse incoming messages. Anyway, we're really close (about 5 days) from having a working jabber API in C++. I have to admit, though, that wxjab and wxxml are probably a bit buggy, their lacking robust error handling, and only support the US-ASCII subset of UTF-8. I'd like to know if either of you would like to volunteer to maintain the wxxml module. We can work on it together, but I'd like someone to be responsible for seeing that the desired improvements actually happen. Even if this means I get assigned to 95% of the code changes, that's fine. I'm throwing 20 hours a week at Convey currently, so that would not be a problem. I would rather not have to do the management of the changes, so I can charge ahead with wxjab. What this role means, is the person would learn the ins and outs of XML in general. They would become familiar with the XML spec so they can reference it when necessary. Then, this person would decide, based on inputs from the others, what features are important to put into the wxxml module. This person would pour over the bugs and feature requests regarding wxxml and filter them as necessary. G'night. Andy |
|
From: Scott L. <sco...@ho...> - 2003-08-04 06:42:05
|
cool! >From: "Andy Ames" <ag...@sb...> >Reply-To: con...@li... >To: "Convey Developers" <con...@li...> >Subject: [convey-developers] convey 0.3 >Date: Thu, 31 Jul 2003 11:36:42 -0700 > >Check out the new Convey 0.3. > >This means you, too, Ed. I added some functionality that we talked about. >There is a single Convey window now, that allows you to connect, >disconnect, >start chats, and do chats. > >Also, the connect dialog box saves previous values in drop down combo >boxes. > >Andy > > > >------------------------------------------------------- >This SF.Net email sponsored by: Free pre-built ASP.NET sites including >Data Reports, E-commerce, Portals, and Forums are available now. >Download today and enter to win an XBOX or Visual Studio .NET. >http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 >_______________________________________________ >convey-developers mailing list >con...@li... >https://lists.sourceforge.net/lists/listinfo/convey-developers _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail |
|
From: Scott L. <sco...@ho...> - 2003-08-04 06:30:52
|
Hello all,
I agree that the fundamental and distinct issues we face are:
(1) non-sequential arrival of messages (We are assuming that a message
once transmitted is guarenteed to arrive at its destination.)
(2) concurrency of canvas events
Andy proposed a canvas-object locking mechanism which employs the chat
session initiator as a resolver or "host". This method addresses the
concurrency problem by permitting only one client to have write-permission
to any object by requiring a handshake with the resolver client.
However, I think the problem of the non-sequential arrival of messages still
exists. For example, assuming client (R1) has received a lock-accept
message from client (I), and (R1) proceeds to make changes to an object.
These changes are propagated to other occupants (R2,R3,...) in the chat room
either by sending a message to all clients (ro...@ja...rver) directly or
by having the message relayed by (I). There may be the possibility that
messages for two modifications, f1(object), f2(object) are generated by (R1)
in close temporal proximity and their arrival at (R2) are in reverse order.
Since, f2(f1(object) != f1(f2(object)), the canvas of (R2) will be different
from that of (R1).
A realistic situation which may reveal this problem is when a user makes
changes to a selected object by quick keystrokes (i.e. [enter],[enter],...).
Due to network conditions, the first message is lost and retransmitted but
the retransmission arrives after the second message.
Another point of consideration in regards to Andy's proposal is this: The
system of networked clients will be limited to the quality of the connection
of the chat session initiator. Furthermore, it will be less a "distributed"
system in which each client is autonomous (although not peer-to-peer since a
Jabber server is involved). This may be relevant for concerns about not
only performance but reliability. What if client (I) suddenly loses network
connection?
Is it possible to solve the concurrency problem without requiring a
"resolver"? Or to use different words: Is it possible to implement an
object locking mechanism without a "resolver"?
There are various aspects which are problematic with the following idea (and
which I'll mention shortly) but let me revisit it. Consider the possibility
of using timestamps for messages and a way to record a
history window of a canvas. Messages for each client are sent to every
other client via a jabber chatroom broadcast. Each message (representing a
canvas modification) are applied to a canvas by also considering its
timestamp -- a modification may be applied retroactively; precedence in
time.
Consider the situation in which (R1) makes a modification f1(object) at t1
and (R2) making modification f2(object) at t2, where t1 < t2. At some time
(t2 + e), (R1)'s canvas would be confronted with
f1(f2(object) and (R2)'s canvas with f2(f1(object). Each client resolves
modifications for its own canvas by referring to the timestamps. Since t1 <
t2, (R1) will simply apply f2. However, if f1(f2(obj) != f2(f1(obj), then
(R2) will undo f2, apply f1, then f2.
However, consider the situation in which f1 is incompatible with f2, at some
time (t2 + e), (R1)'s canvas
would be confronted with f1(f2(object) and (R2)'s canvas with f2(f1(object).
Given the incompatibility of f1 and f2, for (R1), f2 would be ignored For
(R2), f2 would be undone and f1 applied, since t1 < t2.
There are potential issues to this scheme.
(1) How do we accurately sync the timestamp? We may consider including the
travel time of the timestamp packet itself.
(2) How do we deal with a mix of really slow and fast clients? The
conversation would result in wierd retrograde motions. This may be
accounted for by setting the history window so that clients who
don't meet that requirement would not have their messages
recognized. However, this cut-off may result, perhaps in rare
instance, in asymmetries. Consider, the last example, with f2
reaching (R1) but f1 being cut-of by (R2).
(3) The history window, itself, may be problematic. How much would it
impact the memory usage and performance if we keep even a short (a
few seconds) archive of the document?
Scott
>From: "Andy Ames" <ag...@sb...>
>Reply-To: con...@li...
>To: <con...@li...>
>Subject: [convey-developers] concurrency model
>Date: Sun, 3 Aug 2003 14:53:09 -0700
>
>Hey, guys.
>
>I thought I would send some of my thoughts regarding a concurrent object
>model. That way, we can get primed for our design meetings. I've been
>poking
>around the Jabber spec (their calling it XMPP for eXtensible Messaging and
>presence Protocol) and have learned some things.
>
>Basically, when sending an IM from one client to another, there is no
>guarantee regarding the order the messages arrive. This is inherent in the
>IM paradigm. However, this creates a problem for our concurrent object
>model, because we cannot ever make any guarantees regarding the order of
>messages, even if we do a locking mechanism on object selection.
>
>The only solution I can think of is to filter all messages through the
>"host" or initiator of the chat session. That way, all message order and
>concurrent conflicts will be resolved by a single entity responsible for
>resolving it.
>
>We did discuss this solution briefly. But, now I am more convinced that
>this
>is our only option. So, I've outlined a couple scenarios.
>
>These scenarios are one-on-one chat scenarios. The initiator is denoted by
>client 'I' and the receiver by client 'R'. Each scenario has some example
>XML that I made up just for illustration purposes. These are rather long,
>so
>you might want to take some time to digest them. There are exactly two
>scenarios.
>
>1) Scenario 1
>
>a) Client I sends a "New Graphic" event for a rectangle to client R.
>
><message to="R...@do.../Convey"
> from="I...@do.../Convey"
> subject="Hello, there!"
> thread="123456789">
> <new id="rect1">
> <rect x="10" y="20" width="100" height="200"/>
> </new>
></message>
>
>Our Convey for Java automatically selects newly created objects. I think
>for
>our concurrent model, we shouldn't do this automatically to be fair to the
>other participants. For these scenarios, selecting an object puts a lock on
>it.
>
>b) Client R receives the "New Graphic" event for the rectangle from client
>I. Note that it isn't until this point that client R becomes aware of
>client
>I.
>
>At this point, neither Client I nor R has a lock on the newly created
>Graphic. Suppose, then, that Client R attempts to select the rectangle.
>This
>sends a lock request message to client I.
>
><message to="I...@do.../Convey"
> from="R...@do.../Convey"
> thread="123456789">
> <lock-request id="rect1"/>
></message>
>
>c) Client I receives the lock request, and replies with success.
>
><message to="R...@do.../Convey"
> from="I...@do.../Convey"
> thread="123456789">
> <lock-accept id="rect1"/>
></message>
>
>d) Client R receives the lock-accept message, and highlights the rectangle
>with green border. Until now, client R would not be able to manipulate the
>rectangle.
>
>Client R moves the rectangle.
>
><message to="I...@do.../Convey"
> from="R...@do.../Convey"
> thread="123456789">
> <translate id="rect1" x="20" y="30"/>
></message>
>
>e) Client I receives the translation event. Let's say client I now attempts
>to select the rectangle. Client I simply checks its local copy of the DOM
>tree to see if there is already a lock on the graphic. In this case, there
>is, so the rectangle is drawn with a red border.
>
>f) Client R deselects the rectangle. This notifies client I that the lock
>should be released.
>
><message to="I...@do.../Convey"
> from="R...@do.../Convey"
> thread="123456789">
> <lock-release id="rect1"/>
></message>
>
>g) Client I receives the lock release message. The rectangle's border now
>turns green for client I, because it was selected. Now, client I has the
>lock.
>
>2) Scenario 2
>
>a) Client I sends a "New Graphic" event for a rectangle to client R.
>
><message to="R...@do.../Convey"
> from="I...@do.../Convey"
> subject="Hello, there!"
> thread="123456789">
> <new id="rect1">
> <rect x="10" y="20" width="100" height="200"/>
> </new>
></message>
>
>b) Client R receives the "New Graphic" event for the rectangle from client
>I.
>
>c) Client I selects the rectangle. Since client I has the object model, it
>is checked to see if there is already a lock on it. There isn't, so client
>I
>has the lock and the rectangle is drawn with a green border for client I.
>
>Client I moves the rectangle.
>
><message to="R...@do.../Convey"
> from="I...@do.../Convey"
> subject="Hello, there!"
> thread="123456789">
> <translate id="rect1" x="20" y="30"/>
></message>
>
>d) Client R receives the translation event. Client R attempts to select the
>rectangle. This sends a lock request message to client I.
>
><message to="I...@do.../Convey"
> from="R...@do.../Convey"
> thread="123456789">
> <lock-request id="rect1"/>
></message>
>
>e) Client I receives the lock request, but rejects it because client I has
>the lock.
>
><message to="R...@do.../Convey"
> from="I...@do.../Convey"
> thread="123456789">
> <lock-reject id="rect1"/>
></message>
>
>f) Client R receives the lock rejection and paints the rectangle border
>red.
>
>g) Client I deselects the rectangle. This sends a lock accept message to
>client R, because client R had requested the lock previously.
>
><message to="R...@do.../Convey"
> from="I...@do.../Convey"
> thread="123456789">
> <lock-accept id="rect1"/>
></message>
>
>h) Client R receives the lock accept message. The rectangle's border turns
>green and client R has the lock.
>
>An alternative path for {f} and (g) might be...
>
>f) (alt) Client R receives the lock rejection and paints the rectangle
>border red. Then, client R deselects the rectangle. This sends a lock
>release message to client I, indicating that client R no longer wishes to
>lock the rectangle.
>
><message to="R...@do.../Convey"
> from="I...@do.../Convey"
> thread="123456789">
> <lock-release id="rect1"/>
></message>
>
>g) (alt) Client I receives the lock release message. Client I now deselects
>the rectangle. Because client R is no longer waiting for the lock, no lock
>accept message is sent to client R.
>
>Have fun with it. If you have any other scenarios, feel free to add them.
>
>Andy
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>convey-developers mailing list
>con...@li...
>https://lists.sourceforge.net/lists/listinfo/convey-developers
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
|
|
From: Andy A. <ag...@sb...> - 2003-08-03 21:53:19
|
Hey, guys.
I thought I would send some of my thoughts regarding a concurrent object
model. That way, we can get primed for our design meetings. I've been poking
around the Jabber spec (their calling it XMPP for eXtensible Messaging and
presence Protocol) and have learned some things.
Basically, when sending an IM from one client to another, there is no
guarantee regarding the order the messages arrive. This is inherent in the
IM paradigm. However, this creates a problem for our concurrent object
model, because we cannot ever make any guarantees regarding the order of
messages, even if we do a locking mechanism on object selection.
The only solution I can think of is to filter all messages through the
"host" or initiator of the chat session. That way, all message order and
concurrent conflicts will be resolved by a single entity responsible for
resolving it.
We did discuss this solution briefly. But, now I am more convinced that this
is our only option. So, I've outlined a couple scenarios.
These scenarios are one-on-one chat scenarios. The initiator is denoted by
client 'I' and the receiver by client 'R'. Each scenario has some example
XML that I made up just for illustration purposes. These are rather long, so
you might want to take some time to digest them. There are exactly two
scenarios.
1) Scenario 1
a) Client I sends a "New Graphic" event for a rectangle to client R.
<message to="R...@do.../Convey"
from="I...@do.../Convey"
subject="Hello, there!"
thread="123456789">
<new id="rect1">
<rect x="10" y="20" width="100" height="200"/>
</new>
</message>
Our Convey for Java automatically selects newly created objects. I think for
our concurrent model, we shouldn't do this automatically to be fair to the
other participants. For these scenarios, selecting an object puts a lock on
it.
b) Client R receives the "New Graphic" event for the rectangle from client
I. Note that it isn't until this point that client R becomes aware of client
I.
At this point, neither Client I nor R has a lock on the newly created
Graphic. Suppose, then, that Client R attempts to select the rectangle. This
sends a lock request message to client I.
<message to="I...@do.../Convey"
from="R...@do.../Convey"
thread="123456789">
<lock-request id="rect1"/>
</message>
c) Client I receives the lock request, and replies with success.
<message to="R...@do.../Convey"
from="I...@do.../Convey"
thread="123456789">
<lock-accept id="rect1"/>
</message>
d) Client R receives the lock-accept message, and highlights the rectangle
with green border. Until now, client R would not be able to manipulate the
rectangle.
Client R moves the rectangle.
<message to="I...@do.../Convey"
from="R...@do.../Convey"
thread="123456789">
<translate id="rect1" x="20" y="30"/>
</message>
e) Client I receives the translation event. Let's say client I now attempts
to select the rectangle. Client I simply checks its local copy of the DOM
tree to see if there is already a lock on the graphic. In this case, there
is, so the rectangle is drawn with a red border.
f) Client R deselects the rectangle. This notifies client I that the lock
should be released.
<message to="I...@do.../Convey"
from="R...@do.../Convey"
thread="123456789">
<lock-release id="rect1"/>
</message>
g) Client I receives the lock release message. The rectangle's border now
turns green for client I, because it was selected. Now, client I has the
lock.
2) Scenario 2
a) Client I sends a "New Graphic" event for a rectangle to client R.
<message to="R...@do.../Convey"
from="I...@do.../Convey"
subject="Hello, there!"
thread="123456789">
<new id="rect1">
<rect x="10" y="20" width="100" height="200"/>
</new>
</message>
b) Client R receives the "New Graphic" event for the rectangle from client
I.
c) Client I selects the rectangle. Since client I has the object model, it
is checked to see if there is already a lock on it. There isn't, so client I
has the lock and the rectangle is drawn with a green border for client I.
Client I moves the rectangle.
<message to="R...@do.../Convey"
from="I...@do.../Convey"
subject="Hello, there!"
thread="123456789">
<translate id="rect1" x="20" y="30"/>
</message>
d) Client R receives the translation event. Client R attempts to select the
rectangle. This sends a lock request message to client I.
<message to="I...@do.../Convey"
from="R...@do.../Convey"
thread="123456789">
<lock-request id="rect1"/>
</message>
e) Client I receives the lock request, but rejects it because client I has
the lock.
<message to="R...@do.../Convey"
from="I...@do.../Convey"
thread="123456789">
<lock-reject id="rect1"/>
</message>
f) Client R receives the lock rejection and paints the rectangle border red.
g) Client I deselects the rectangle. This sends a lock accept message to
client R, because client R had requested the lock previously.
<message to="R...@do.../Convey"
from="I...@do.../Convey"
thread="123456789">
<lock-accept id="rect1"/>
</message>
h) Client R receives the lock accept message. The rectangle's border turns
green and client R has the lock.
An alternative path for {f} and (g) might be...
f) (alt) Client R receives the lock rejection and paints the rectangle
border red. Then, client R deselects the rectangle. This sends a lock
release message to client I, indicating that client R no longer wishes to
lock the rectangle.
<message to="R...@do.../Convey"
from="I...@do.../Convey"
thread="123456789">
<lock-release id="rect1"/>
</message>
g) (alt) Client I receives the lock release message. Client I now deselects
the rectangle. Because client R is no longer waiting for the lock, no lock
accept message is sent to client R.
Have fun with it. If you have any other scenarios, feel free to add them.
Andy
|
|
From: Andy A. <ag...@sb...> - 2003-08-03 21:29:13
|
Actually, if we want to, we can dig into Muse code. To do that, we have to recompile the Muse jar with debug turned on. We do have the Muse sources, so we can so this. Once we've compiled it in debug mode, we can set up the project properties to know where to find the Muse sources. Then, we can set breakpoints and step into Muse. Also, that error looks like it might be deeper than Muse. It might be in the SAX XML parser, JDOM, or Crimson. To effectively track the bug, we'll need to get all these APIs compiled in debug mode if they aren't already. It could be a major undertaking, nonetheless. Andy -----Original Message----- From: con...@li... [mailto:con...@li...]On Behalf Of Andy Ames Sent: Sunday, August 03, 2003 2:08 PM To: con...@li... Subject: RE: [convey-developers] Connect/Chat dialogs That's Muse again. We cannot solve it. All we can do is try again. Andy -----Original Message----- From: con...@li... [mailto:con...@li...]On Behalf Of eD Braunhut Sent: Sunday, August 03, 2003 1:38 PM To: con...@li... Subject: Re: [convey-developers] Connect/Chat dialogs O.k. I made it past the last exception but when trying to log in I am getting "End of Entity is not allowed; an end tag is missing. I'll see what the problem might be. Perhaps the code that I commented out the last time we did distance co-debugging. On Sunday, August 3, 2003, at 12:00 PM, Andy Ames wrote: > Actually, it's trying to read your old .connect file, which is a > different > format than the one we're using now. Just delete it. > > Andy > > -----Original Message----- > From: con...@li... > [mailto:con...@li...]On Behalf Of Ed > Braunhut > Sent: Sunday, August 03, 2003 8:18 AM > To: con...@li... > Subject: Re: [convey-developers] Connect/Chat dialogs > > > Hi Andy, > I'm get a java.io.EOFException with this new code as soon > as I click the connect button. I'll look further into this > but I suspect it may be because EOLs are handled using > different symbols on different platforms. I'll submit a bug > report with the details or you can check the dump below. > -eD > > /System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/bin/ > java > -classpath > "/usr/local/conveyrep/convey/classes:/usr/local/conveyrep/convey/lib/ > crimson > -1.1.3.jar:/usr/local/conveyrep/convey/lib/jakarta-oro-2.0.4.jar:/usr/ > local/ > conveyrep/convey/lib/jdom-b7.jar:/usr/local/conveyrep/convey/lib/jaxp- > 1.1.ja > r:/usr/local/conveyrep/convey/lib/muse-0.72.jar:/System/Library/ > Frameworks/J > avaVM.framework/Versions/1.3.1/Classes/classes.jar:/System/Library/ > Framework > s/JavaVM.framework/Versions/1.3.1/Classes/i18n.jar:/System/Library/ > Framework > s/JavaVM.framework/Versions/1.3.1/Classes/sunrsasign.jar:/System/ > Library/Fra > meworks/JavaVM.framework/Versions/1.3.1/Classes/ui.jar:/System/ > Library/Frame > works/JavaVM.framework/Versions/1.3.1/Home/lib/dt.jar:/System/Library/ > Framew > orks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/jcert.jar:/System/ > Library/ > Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/jnet.jar:/ > System/Lib > rary/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/ > jpda.jar:/Syste > m/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/ > jsse.jar" > org.convey.ConveyFrame > java.io.EOFException > at > java.io.DataInputStream.readInt(DataInputStream.java:338) > at > java.io.ObjectInputStream.readInt(ObjectInputStream.java:1975) > at > org.convey.ConnectDialog.readExternal(ConnectDialog.java:369) > at org.convey.ConveyFrame.connect(ConveyFrame.java:1190) > at > org.convey.ConveyFrame$2.actionPerformed(ConveyFrame.java:293) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1453 > ) > at > javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Abstract > Butto > n.java:1507) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.j > ava:3 > 73) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:245) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonLis > tener > .java:211) > at > com.apple.mrj.swing.ThemeButtonListener.mouseReleased(ThemeButtonListen > er.ja > va:111) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:225 > ) > at > java.awt.Component.processMouseEvent(Component.java:3711) > at java.awt.Component.processEvent(Component.java:3540) > at java.awt.Container.processEvent(Container.java:1159) > at > java.awt.Component.dispatchEventImpl(Component.java:2589) > at > java.awt.Container.dispatchEventImpl(Container.java:1208) > at java.awt.Component.dispatchEvent(Component.java:2493) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2446) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:2211) > at > java.awt.LightweightDispatcher.dispatchEvent(Container.java:2120) > at > java.awt.Container.dispatchEventImpl(Container.java:1195) > at java.awt.Window.dispatchEventImpl(Window.java:966) > at java.awt.Component.dispatchEvent(Component.java:2493) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:334) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThre > ad.ja > va:126) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread > .java > :93) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:88) > at > java.awt.EventDispatchThread.run(EventDispatchThread.java:80) > Exception occurred during event dispatching: > java.lang.NullPointerException > at org.convey.ConnectDialog.show(ConnectDialog.java:227) > at org.convey.ConveyFrame.connect(ConveyFrame.java:1201) > at > org.convey.ConveyFrame$2.actionPerformed(ConveyFrame.java:293) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1453 > ) > at > javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Abstract > Butto > n.java:1507) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.j > ava:3 > 73) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:245) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonLis > tener > .java:211) > at > com.apple.mrj.swing.ThemeButtonListener.mouseReleased(ThemeButtonListen > er.ja > va:111) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:225 > ) > at > java.awt.Component.processMouseEvent(Component.java:3711) > at java.awt.Component.processEvent(Component.java:3540) > at java.awt.Container.processEvent(Container.java:1159) > at > java.awt.Component.dispatchEventImpl(Component.java:2589) > at > java.awt.Container.dispatchEventImpl(Container.java:1208) > at java.awt.Component.dispatchEvent(Component.java:2493) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2446) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:2211) > at > java.awt.LightweightDispatcher.dispatchEvent(Container.java:2120) > at > java.awt.Container.dispatchEventImpl(Container.java:1195) > at java.awt.Window.dispatchEventImpl(Window.java:966) > at java.awt.Component.dispatchEvent(Component.java:2493) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:334) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThre > ad.ja > va:126) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread > .java > :93) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:88) > at > java.awt.EventDispatchThread.run(EventDispatchThread.java:80) > > > On Fri, 1 Aug 2003 04:13:22 -0700 > "Andy Ames" <ag...@sb...> wrote: >> Okay, the connect and chat dialogs are fully functional. >> They persist all >> previously entered values between executions of Convey. >> >> Also, you can now choose the "Save Password" checkbox in >> the connect dialog. >> >> Connecting to the network is now down to two actions: 1) >> open the connect >> dialog, and 2) press "Ok". >> >> What is not implemented yet, is the "Auto Connect" >> checkbox. I'm not sure >> where this would go. It doesn't make sense to put it in >> the Connect dialog >> lower than the server drop down because only one >> server/user combination can >> have the Auto Connect setting. This makes me think the >> checkbox should be at >> the top of the dialog even before the server dropdown. >> But it doesn't look >> good there. >> >> I also thought about putting it as a Convey menu item >> that is toggled >> between on and off. Perhaps with a toolbar toggle button >> connected to it as >> well. >> >> Once we get that feature, finally, you'll be able to do >> nothing but run >> Convey and you're logged in. >> >> Oh, but currently, the passwords are being stored in >> plain ASCII if you >> choose "Save Password." The config file is in your user >> home directory, but >> that's still not acceptable. We need to encrypt it using >> SHA. >> >> Andy >> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by: Free pre-built ASP.NET >> sites including >> Data Reports, E-commerce, Portals, and Forums are >> available now. >> Download today and enter to win an XBOX or Visual Studio >> .NET. >> > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 >> _______________________________________________ >> convey-developers mailing list >> con...@li... >> > https://lists.sourceforge.net/lists/listinfo/convey-developers > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers > ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ convey-developers mailing list con...@li... https://lists.sourceforge.net/lists/listinfo/convey-developers ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ convey-developers mailing list con...@li... https://lists.sourceforge.net/lists/listinfo/convey-developers |
|
From: Andy A. <ag...@sb...> - 2003-08-03 21:08:33
|
That's Muse again. We cannot solve it. All we can do is try again. Andy -----Original Message----- From: con...@li... [mailto:con...@li...]On Behalf Of eD Braunhut Sent: Sunday, August 03, 2003 1:38 PM To: con...@li... Subject: Re: [convey-developers] Connect/Chat dialogs O.k. I made it past the last exception but when trying to log in I am getting "End of Entity is not allowed; an end tag is missing. I'll see what the problem might be. Perhaps the code that I commented out the last time we did distance co-debugging. On Sunday, August 3, 2003, at 12:00 PM, Andy Ames wrote: > Actually, it's trying to read your old .connect file, which is a > different > format than the one we're using now. Just delete it. > > Andy > > -----Original Message----- > From: con...@li... > [mailto:con...@li...]On Behalf Of Ed > Braunhut > Sent: Sunday, August 03, 2003 8:18 AM > To: con...@li... > Subject: Re: [convey-developers] Connect/Chat dialogs > > > Hi Andy, > I'm get a java.io.EOFException with this new code as soon > as I click the connect button. I'll look further into this > but I suspect it may be because EOLs are handled using > different symbols on different platforms. I'll submit a bug > report with the details or you can check the dump below. > -eD > > /System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/bin/ > java > -classpath > "/usr/local/conveyrep/convey/classes:/usr/local/conveyrep/convey/lib/ > crimson > -1.1.3.jar:/usr/local/conveyrep/convey/lib/jakarta-oro-2.0.4.jar:/usr/ > local/ > conveyrep/convey/lib/jdom-b7.jar:/usr/local/conveyrep/convey/lib/jaxp- > 1.1.ja > r:/usr/local/conveyrep/convey/lib/muse-0.72.jar:/System/Library/ > Frameworks/J > avaVM.framework/Versions/1.3.1/Classes/classes.jar:/System/Library/ > Framework > s/JavaVM.framework/Versions/1.3.1/Classes/i18n.jar:/System/Library/ > Framework > s/JavaVM.framework/Versions/1.3.1/Classes/sunrsasign.jar:/System/ > Library/Fra > meworks/JavaVM.framework/Versions/1.3.1/Classes/ui.jar:/System/ > Library/Frame > works/JavaVM.framework/Versions/1.3.1/Home/lib/dt.jar:/System/Library/ > Framew > orks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/jcert.jar:/System/ > Library/ > Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/jnet.jar:/ > System/Lib > rary/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/ > jpda.jar:/Syste > m/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/ > jsse.jar" > org.convey.ConveyFrame > java.io.EOFException > at > java.io.DataInputStream.readInt(DataInputStream.java:338) > at > java.io.ObjectInputStream.readInt(ObjectInputStream.java:1975) > at > org.convey.ConnectDialog.readExternal(ConnectDialog.java:369) > at org.convey.ConveyFrame.connect(ConveyFrame.java:1190) > at > org.convey.ConveyFrame$2.actionPerformed(ConveyFrame.java:293) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1453 > ) > at > javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Abstract > Butto > n.java:1507) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.j > ava:3 > 73) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:245) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonLis > tener > .java:211) > at > com.apple.mrj.swing.ThemeButtonListener.mouseReleased(ThemeButtonListen > er.ja > va:111) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:225 > ) > at > java.awt.Component.processMouseEvent(Component.java:3711) > at java.awt.Component.processEvent(Component.java:3540) > at java.awt.Container.processEvent(Container.java:1159) > at > java.awt.Component.dispatchEventImpl(Component.java:2589) > at > java.awt.Container.dispatchEventImpl(Container.java:1208) > at java.awt.Component.dispatchEvent(Component.java:2493) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2446) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:2211) > at > java.awt.LightweightDispatcher.dispatchEvent(Container.java:2120) > at > java.awt.Container.dispatchEventImpl(Container.java:1195) > at java.awt.Window.dispatchEventImpl(Window.java:966) > at java.awt.Component.dispatchEvent(Component.java:2493) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:334) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThre > ad.ja > va:126) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread > .java > :93) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:88) > at > java.awt.EventDispatchThread.run(EventDispatchThread.java:80) > Exception occurred during event dispatching: > java.lang.NullPointerException > at org.convey.ConnectDialog.show(ConnectDialog.java:227) > at org.convey.ConveyFrame.connect(ConveyFrame.java:1201) > at > org.convey.ConveyFrame$2.actionPerformed(ConveyFrame.java:293) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1453 > ) > at > javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Abstract > Butto > n.java:1507) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.j > ava:3 > 73) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:245) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonLis > tener > .java:211) > at > com.apple.mrj.swing.ThemeButtonListener.mouseReleased(ThemeButtonListen > er.ja > va:111) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:225 > ) > at > java.awt.Component.processMouseEvent(Component.java:3711) > at java.awt.Component.processEvent(Component.java:3540) > at java.awt.Container.processEvent(Container.java:1159) > at > java.awt.Component.dispatchEventImpl(Component.java:2589) > at > java.awt.Container.dispatchEventImpl(Container.java:1208) > at java.awt.Component.dispatchEvent(Component.java:2493) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2446) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:2211) > at > java.awt.LightweightDispatcher.dispatchEvent(Container.java:2120) > at > java.awt.Container.dispatchEventImpl(Container.java:1195) > at java.awt.Window.dispatchEventImpl(Window.java:966) > at java.awt.Component.dispatchEvent(Component.java:2493) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:334) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThre > ad.ja > va:126) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread > .java > :93) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:88) > at > java.awt.EventDispatchThread.run(EventDispatchThread.java:80) > > > On Fri, 1 Aug 2003 04:13:22 -0700 > "Andy Ames" <ag...@sb...> wrote: >> Okay, the connect and chat dialogs are fully functional. >> They persist all >> previously entered values between executions of Convey. >> >> Also, you can now choose the "Save Password" checkbox in >> the connect dialog. >> >> Connecting to the network is now down to two actions: 1) >> open the connect >> dialog, and 2) press "Ok". >> >> What is not implemented yet, is the "Auto Connect" >> checkbox. I'm not sure >> where this would go. It doesn't make sense to put it in >> the Connect dialog >> lower than the server drop down because only one >> server/user combination can >> have the Auto Connect setting. This makes me think the >> checkbox should be at >> the top of the dialog even before the server dropdown. >> But it doesn't look >> good there. >> >> I also thought about putting it as a Convey menu item >> that is toggled >> between on and off. Perhaps with a toolbar toggle button >> connected to it as >> well. >> >> Once we get that feature, finally, you'll be able to do >> nothing but run >> Convey and you're logged in. >> >> Oh, but currently, the passwords are being stored in >> plain ASCII if you >> choose "Save Password." The config file is in your user >> home directory, but >> that's still not acceptable. We need to encrypt it using >> SHA. >> >> Andy >> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by: Free pre-built ASP.NET >> sites including >> Data Reports, E-commerce, Portals, and Forums are >> available now. >> Download today and enter to win an XBOX or Visual Studio >> .NET. >> > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 >> _______________________________________________ >> convey-developers mailing list >> con...@li... >> > https://lists.sourceforge.net/lists/listinfo/convey-developers > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers > ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ convey-developers mailing list con...@li... https://lists.sourceforge.net/lists/listinfo/convey-developers |
|
From: eD B. <edb...@ca...> - 2003-08-03 20:35:44
|
O.k. I made it past the last exception but when trying to log in I am getting "End of Entity is not allowed; an end tag is missing. I'll see what the problem might be. Perhaps the code that I commented out the last time we did distance co-debugging. On Sunday, August 3, 2003, at 12:00 PM, Andy Ames wrote: > Actually, it's trying to read your old .connect file, which is a > different > format than the one we're using now. Just delete it. > > Andy > > -----Original Message----- > From: con...@li... > [mailto:con...@li...]On Behalf Of Ed > Braunhut > Sent: Sunday, August 03, 2003 8:18 AM > To: con...@li... > Subject: Re: [convey-developers] Connect/Chat dialogs > > > Hi Andy, > I'm get a java.io.EOFException with this new code as soon > as I click the connect button. I'll look further into this > but I suspect it may be because EOLs are handled using > different symbols on different platforms. I'll submit a bug > report with the details or you can check the dump below. > -eD > > /System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/bin/ > java > -classpath > "/usr/local/conveyrep/convey/classes:/usr/local/conveyrep/convey/lib/ > crimson > -1.1.3.jar:/usr/local/conveyrep/convey/lib/jakarta-oro-2.0.4.jar:/usr/ > local/ > conveyrep/convey/lib/jdom-b7.jar:/usr/local/conveyrep/convey/lib/jaxp- > 1.1.ja > r:/usr/local/conveyrep/convey/lib/muse-0.72.jar:/System/Library/ > Frameworks/J > avaVM.framework/Versions/1.3.1/Classes/classes.jar:/System/Library/ > Framework > s/JavaVM.framework/Versions/1.3.1/Classes/i18n.jar:/System/Library/ > Framework > s/JavaVM.framework/Versions/1.3.1/Classes/sunrsasign.jar:/System/ > Library/Fra > meworks/JavaVM.framework/Versions/1.3.1/Classes/ui.jar:/System/ > Library/Frame > works/JavaVM.framework/Versions/1.3.1/Home/lib/dt.jar:/System/Library/ > Framew > orks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/jcert.jar:/System/ > Library/ > Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/jnet.jar:/ > System/Lib > rary/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/ > jpda.jar:/Syste > m/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/ > jsse.jar" > org.convey.ConveyFrame > java.io.EOFException > at > java.io.DataInputStream.readInt(DataInputStream.java:338) > at > java.io.ObjectInputStream.readInt(ObjectInputStream.java:1975) > at > org.convey.ConnectDialog.readExternal(ConnectDialog.java:369) > at org.convey.ConveyFrame.connect(ConveyFrame.java:1190) > at > org.convey.ConveyFrame$2.actionPerformed(ConveyFrame.java:293) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1453 > ) > at > javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Abstract > Butto > n.java:1507) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.j > ava:3 > 73) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:245) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonLis > tener > .java:211) > at > com.apple.mrj.swing.ThemeButtonListener.mouseReleased(ThemeButtonListen > er.ja > va:111) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:225 > ) > at > java.awt.Component.processMouseEvent(Component.java:3711) > at java.awt.Component.processEvent(Component.java:3540) > at java.awt.Container.processEvent(Container.java:1159) > at > java.awt.Component.dispatchEventImpl(Component.java:2589) > at > java.awt.Container.dispatchEventImpl(Container.java:1208) > at java.awt.Component.dispatchEvent(Component.java:2493) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2446) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:2211) > at > java.awt.LightweightDispatcher.dispatchEvent(Container.java:2120) > at > java.awt.Container.dispatchEventImpl(Container.java:1195) > at java.awt.Window.dispatchEventImpl(Window.java:966) > at java.awt.Component.dispatchEvent(Component.java:2493) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:334) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThre > ad.ja > va:126) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread > .java > :93) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:88) > at > java.awt.EventDispatchThread.run(EventDispatchThread.java:80) > Exception occurred during event dispatching: > java.lang.NullPointerException > at org.convey.ConnectDialog.show(ConnectDialog.java:227) > at org.convey.ConveyFrame.connect(ConveyFrame.java:1201) > at > org.convey.ConveyFrame$2.actionPerformed(ConveyFrame.java:293) > at > javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1453 > ) > at > javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Abstract > Butto > n.java:1507) > at > javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.j > ava:3 > 73) > at > javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:245) > at > javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonLis > tener > .java:211) > at > com.apple.mrj.swing.ThemeButtonListener.mouseReleased(ThemeButtonListen > er.ja > va:111) > at > java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:225 > ) > at > java.awt.Component.processMouseEvent(Component.java:3711) > at java.awt.Component.processEvent(Component.java:3540) > at java.awt.Container.processEvent(Container.java:1159) > at > java.awt.Component.dispatchEventImpl(Component.java:2589) > at > java.awt.Container.dispatchEventImpl(Container.java:1208) > at java.awt.Component.dispatchEvent(Component.java:2493) > at > java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2446) > at > java.awt.LightweightDispatcher.processMouseEvent(Container.java:2211) > at > java.awt.LightweightDispatcher.dispatchEvent(Container.java:2120) > at > java.awt.Container.dispatchEventImpl(Container.java:1195) > at java.awt.Window.dispatchEventImpl(Window.java:966) > at java.awt.Component.dispatchEvent(Component.java:2493) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:334) > at > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThre > ad.ja > va:126) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread > .java > :93) > at > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:88) > at > java.awt.EventDispatchThread.run(EventDispatchThread.java:80) > > > On Fri, 1 Aug 2003 04:13:22 -0700 > "Andy Ames" <ag...@sb...> wrote: >> Okay, the connect and chat dialogs are fully functional. >> They persist all >> previously entered values between executions of Convey. >> >> Also, you can now choose the "Save Password" checkbox in >> the connect dialog. >> >> Connecting to the network is now down to two actions: 1) >> open the connect >> dialog, and 2) press "Ok". >> >> What is not implemented yet, is the "Auto Connect" >> checkbox. I'm not sure >> where this would go. It doesn't make sense to put it in >> the Connect dialog >> lower than the server drop down because only one >> server/user combination can >> have the Auto Connect setting. This makes me think the >> checkbox should be at >> the top of the dialog even before the server dropdown. >> But it doesn't look >> good there. >> >> I also thought about putting it as a Convey menu item >> that is toggled >> between on and off. Perhaps with a toolbar toggle button >> connected to it as >> well. >> >> Once we get that feature, finally, you'll be able to do >> nothing but run >> Convey and you're logged in. >> >> Oh, but currently, the passwords are being stored in >> plain ASCII if you >> choose "Save Password." The config file is in your user >> home directory, but >> that's still not acceptable. We need to encrypt it using >> SHA. >> >> Andy >> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by: Free pre-built ASP.NET >> sites including >> Data Reports, E-commerce, Portals, and Forums are >> available now. >> Download today and enter to win an XBOX or Visual Studio >> .NET. >> > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 >> _______________________________________________ >> convey-developers mailing list >> con...@li... >> > https://lists.sourceforge.net/lists/listinfo/convey-developers > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers > |
|
From: Andy A. <ag...@sb...> - 2003-08-03 19:00:33
|
Actually, it's trying to read your old .connect file, which is a different format than the one we're using now. Just delete it. Andy -----Original Message----- From: con...@li... [mailto:con...@li...]On Behalf Of Ed Braunhut Sent: Sunday, August 03, 2003 8:18 AM To: con...@li... Subject: Re: [convey-developers] Connect/Chat dialogs Hi Andy, I'm get a java.io.EOFException with this new code as soon as I click the connect button. I'll look further into this but I suspect it may be because EOLs are handled using different symbols on different platforms. I'll submit a bug report with the details or you can check the dump below. -eD /System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/bin/java -classpath "/usr/local/conveyrep/convey/classes:/usr/local/conveyrep/convey/lib/crimson -1.1.3.jar:/usr/local/conveyrep/convey/lib/jakarta-oro-2.0.4.jar:/usr/local/ conveyrep/convey/lib/jdom-b7.jar:/usr/local/conveyrep/convey/lib/jaxp-1.1.ja r:/usr/local/conveyrep/convey/lib/muse-0.72.jar:/System/Library/Frameworks/J avaVM.framework/Versions/1.3.1/Classes/classes.jar:/System/Library/Framework s/JavaVM.framework/Versions/1.3.1/Classes/i18n.jar:/System/Library/Framework s/JavaVM.framework/Versions/1.3.1/Classes/sunrsasign.jar:/System/Library/Fra meworks/JavaVM.framework/Versions/1.3.1/Classes/ui.jar:/System/Library/Frame works/JavaVM.framework/Versions/1.3.1/Home/lib/dt.jar:/System/Library/Framew orks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/jcert.jar:/System/Library/ Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/jnet.jar:/System/Lib rary/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/jpda.jar:/Syste m/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/jsse.jar" org.convey.ConveyFrame java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:338) at java.io.ObjectInputStream.readInt(ObjectInputStream.java:1975) at org.convey.ConnectDialog.readExternal(ConnectDialog.java:369) at org.convey.ConveyFrame.connect(ConveyFrame.java:1190) at org.convey.ConveyFrame$2.actionPerformed(ConveyFrame.java:293) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1453) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButto n.java:1507) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:3 73) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:245) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener .java:211) at com.apple.mrj.swing.ThemeButtonListener.mouseReleased(ThemeButtonListener.ja va:111) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:225) at java.awt.Component.processMouseEvent(Component.java:3711) at java.awt.Component.processEvent(Component.java:3540) at java.awt.Container.processEvent(Container.java:1159) at java.awt.Component.dispatchEventImpl(Component.java:2589) at java.awt.Container.dispatchEventImpl(Container.java:1208) at java.awt.Component.dispatchEvent(Component.java:2493) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2446) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:2211) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2120) at java.awt.Container.dispatchEventImpl(Container.java:1195) at java.awt.Window.dispatchEventImpl(Window.java:966) at java.awt.Component.dispatchEvent(Component.java:2493) at java.awt.EventQueue.dispatchEvent(EventQueue.java:334) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja va:126) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java :93) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:88) at java.awt.EventDispatchThread.run(EventDispatchThread.java:80) Exception occurred during event dispatching: java.lang.NullPointerException at org.convey.ConnectDialog.show(ConnectDialog.java:227) at org.convey.ConveyFrame.connect(ConveyFrame.java:1201) at org.convey.ConveyFrame$2.actionPerformed(ConveyFrame.java:293) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1453) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButto n.java:1507) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:3 73) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:245) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener .java:211) at com.apple.mrj.swing.ThemeButtonListener.mouseReleased(ThemeButtonListener.ja va:111) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:225) at java.awt.Component.processMouseEvent(Component.java:3711) at java.awt.Component.processEvent(Component.java:3540) at java.awt.Container.processEvent(Container.java:1159) at java.awt.Component.dispatchEventImpl(Component.java:2589) at java.awt.Container.dispatchEventImpl(Container.java:1208) at java.awt.Component.dispatchEvent(Component.java:2493) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2446) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:2211) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2120) at java.awt.Container.dispatchEventImpl(Container.java:1195) at java.awt.Window.dispatchEventImpl(Window.java:966) at java.awt.Component.dispatchEvent(Component.java:2493) at java.awt.EventQueue.dispatchEvent(EventQueue.java:334) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.ja va:126) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java :93) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:88) at java.awt.EventDispatchThread.run(EventDispatchThread.java:80) On Fri, 1 Aug 2003 04:13:22 -0700 "Andy Ames" <ag...@sb...> wrote: > Okay, the connect and chat dialogs are fully functional. > They persist all > previously entered values between executions of Convey. > > Also, you can now choose the "Save Password" checkbox in > the connect dialog. > > Connecting to the network is now down to two actions: 1) > open the connect > dialog, and 2) press "Ok". > > What is not implemented yet, is the "Auto Connect" > checkbox. I'm not sure > where this would go. It doesn't make sense to put it in > the Connect dialog > lower than the server drop down because only one > server/user combination can > have the Auto Connect setting. This makes me think the > checkbox should be at > the top of the dialog even before the server dropdown. > But it doesn't look > good there. > > I also thought about putting it as a Convey menu item > that is toggled > between on and off. Perhaps with a toolbar toggle button > connected to it as > well. > > Once we get that feature, finally, you'll be able to do > nothing but run > Convey and you're logged in. > > Oh, but currently, the passwords are being stored in > plain ASCII if you > choose "Save Password." The config file is in your user > home directory, but > that's still not acceptable. We need to encrypt it using > SHA. > > Andy > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET > sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual Studio > .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ convey-developers mailing list con...@li... https://lists.sourceforge.net/lists/listinfo/convey-developers |
|
From: Ed B. <edb...@ca...> - 2003-08-03 15:18:30
|
Hi Andy, I'm get a java.io.EOFException with this new code as soon as I click the connect button. I'll look further into this but I suspect it may be because EOLs are handled using different symbols on different platforms. I'll submit a bug report with the details or you can check the dump below. -eD /System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/bin/java -classpath "/usr/local/conveyrep/convey/classes:/usr/local/conveyrep/convey/lib/crimson-1.1.3.jar:/usr/local/conveyrep/convey/lib/jakarta-oro-2.0.4.jar:/usr/local/conveyrep/convey/lib/jdom-b7.jar:/usr/local/conveyrep/convey/lib/jaxp-1.1.jar:/usr/local/conveyrep/convey/lib/muse-0.72.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Classes/classes.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Classes/i18n.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Classes/sunrsasign.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Classes/ui.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/dt.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/jcert.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/jnet.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/jpda.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home/lib/ext/jsse.jar" org.convey.ConveyFrame java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:338) at java.io.ObjectInputStream.readInt(ObjectInputStream.java:1975) at org.convey.ConnectDialog.readExternal(ConnectDialog.java:369) at org.convey.ConveyFrame.connect(ConveyFrame.java:1190) at org.convey.ConveyFrame$2.actionPerformed(ConveyFrame.java:293) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1453) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1507) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:373) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:245) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:211) at com.apple.mrj.swing.ThemeButtonListener.mouseReleased(ThemeButtonListener.java:111) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:225) at java.awt.Component.processMouseEvent(Component.java:3711) at java.awt.Component.processEvent(Component.java:3540) at java.awt.Container.processEvent(Container.java:1159) at java.awt.Component.dispatchEventImpl(Component.java:2589) at java.awt.Container.dispatchEventImpl(Container.java:1208) at java.awt.Component.dispatchEvent(Component.java:2493) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2446) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:2211) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2120) at java.awt.Container.dispatchEventImpl(Container.java:1195) at java.awt.Window.dispatchEventImpl(Window.java:966) at java.awt.Component.dispatchEvent(Component.java:2493) at java.awt.EventQueue.dispatchEvent(EventQueue.java:334) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:126) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:93) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:88) at java.awt.EventDispatchThread.run(EventDispatchThread.java:80) Exception occurred during event dispatching: java.lang.NullPointerException at org.convey.ConnectDialog.show(ConnectDialog.java:227) at org.convey.ConveyFrame.connect(ConveyFrame.java:1201) at org.convey.ConveyFrame$2.actionPerformed(ConveyFrame.java:293) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1453) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1507) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:373) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:245) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:211) at com.apple.mrj.swing.ThemeButtonListener.mouseReleased(ThemeButtonListener.java:111) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:225) at java.awt.Component.processMouseEvent(Component.java:3711) at java.awt.Component.processEvent(Component.java:3540) at java.awt.Container.processEvent(Container.java:1159) at java.awt.Component.dispatchEventImpl(Component.java:2589) at java.awt.Container.dispatchEventImpl(Container.java:1208) at java.awt.Component.dispatchEvent(Component.java:2493) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2446) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:2211) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2120) at java.awt.Container.dispatchEventImpl(Container.java:1195) at java.awt.Window.dispatchEventImpl(Window.java:966) at java.awt.Component.dispatchEvent(Component.java:2493) at java.awt.EventQueue.dispatchEvent(EventQueue.java:334) at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:126) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:93) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:88) at java.awt.EventDispatchThread.run(EventDispatchThread.java:80) On Fri, 1 Aug 2003 04:13:22 -0700 "Andy Ames" <ag...@sb...> wrote: > Okay, the connect and chat dialogs are fully functional. > They persist all > previously entered values between executions of Convey. > > Also, you can now choose the "Save Password" checkbox in > the connect dialog. > > Connecting to the network is now down to two actions: 1) > open the connect > dialog, and 2) press "Ok". > > What is not implemented yet, is the "Auto Connect" > checkbox. I'm not sure > where this would go. It doesn't make sense to put it in > the Connect dialog > lower than the server drop down because only one > server/user combination can > have the Auto Connect setting. This makes me think the > checkbox should be at > the top of the dialog even before the server dropdown. > But it doesn't look > good there. > > I also thought about putting it as a Convey menu item > that is toggled > between on and off. Perhaps with a toolbar toggle button > connected to it as > well. > > Once we get that feature, finally, you'll be able to do > nothing but run > Convey and you're logged in. > > Oh, but currently, the passwords are being stored in > plain ASCII if you > choose "Save Password." The config file is in your user > home directory, but > that's still not acceptable. We need to encrypt it using > SHA. > > Andy > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET > sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual Studio > .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers |
|
From: Ed B. <edb...@ca...> - 2003-08-03 15:11:12
|
Andy, I will be definitely be available Sun (today) through Thurs from 11:30 to 6pm at the MLC. It would certainly be dramatic to have a working wxConvey up by Late September, especially using a transaction model for dealing with concurrency in networked events. Scott, how does this sound to you? I know you said you would be interested in participating in the development of a new Convey with C++. Was this because we would be starting from the beginning (which isn't entirely true because of the experience we've had so far implementing Convey in Java) or because we will be writing it in C++ instead of Java or because of the new design? eD On Fri, 1 Aug 2003 22:12:48 -0700 "Andy Ames" <ag...@sb...> wrote: > The XML Inputter now uses expat for the parser. It was a > little troublesome > getting expat to build. So, currently, the wxxml module > is only set up to > build on MSW. > > Ed, next week, I'd like to get it set up to build on your > Mac OS X. > > Thanks again for the tip, Scott. > > Next up, is to build a Jabber streams API using wxxml. > wxJabber? > > I also want to start writing the wxwindows Convey GUI, > such as menus and > toolbars. Ed, for a couple weeks, I've been secretly > planning on getting > wxwindows Convey caught up with Java Convey by the time > Fall begins. ;) > > I mean my fall quarter, which is after your fall semester > begins. Late > september. I'd like to start scheduling design meetings > next week. What's > your availability? > > Andy > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET > sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual Studio > .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers |
|
From: Andy A. <ag...@sb...> - 2003-08-02 05:12:51
|
The XML Inputter now uses expat for the parser. It was a little troublesome getting expat to build. So, currently, the wxxml module is only set up to build on MSW. Ed, next week, I'd like to get it set up to build on your Mac OS X. Thanks again for the tip, Scott. Next up, is to build a Jabber streams API using wxxml. wxJabber? I also want to start writing the wxwindows Convey GUI, such as menus and toolbars. Ed, for a couple weeks, I've been secretly planning on getting wxwindows Convey caught up with Java Convey by the time Fall begins. ;) I mean my fall quarter, which is after your fall semester begins. Late september. I'd like to start scheduling design meetings next week. What's your availability? Andy |
|
From: Andy A. <ag...@sb...> - 2003-08-01 11:12:49
|
Okay, the connect and chat dialogs are fully functional. They persist all previously entered values between executions of Convey. Also, you can now choose the "Save Password" checkbox in the connect dialog. Connecting to the network is now down to two actions: 1) open the connect dialog, and 2) press "Ok". What is not implemented yet, is the "Auto Connect" checkbox. I'm not sure where this would go. It doesn't make sense to put it in the Connect dialog lower than the server drop down because only one server/user combination can have the Auto Connect setting. This makes me think the checkbox should be at the top of the dialog even before the server dropdown. But it doesn't look good there. I also thought about putting it as a Convey menu item that is toggled between on and off. Perhaps with a toolbar toggle button connected to it as well. Once we get that feature, finally, you'll be able to do nothing but run Convey and you're logged in. Oh, but currently, the passwords are being stored in plain ASCII if you choose "Save Password." The config file is in your user home directory, but that's still not acceptable. We need to encrypt it using SHA. Andy |
|
From: eD B. <edb...@ca...> - 2003-07-31 21:08:08
|
It's working...I was just being a dumbhead: I had to set up the environment variable CVS_RSH again. I forgot when I reinstalled my OS I lost all my initialization scripts. So, hey, it works and it's very cool. I was thinking it would be nice to have the original conveyFrame buttons on the same line but separated from the edit buttons. It would maximize drawing space. Also, I just finished implementing the closable panes, the code of which, I merged with yours. (not really English speak there). I'll commit it now. It works fine. Ed On Thursday, July 31, 2003, at 01:12 PM, Andy Ames wrote: > The CVS server is working on my end. > > Try again. > > One thing to look for when you get Convey updated, in your HOME dir, a > configuration directory is created called ".convey/". In this > directory, a > file is created called ".connect" > > This file stores the contents of the ConnectDialog. The first time you > run > Convey, default contents are placed in the ConnectDialog because > ".connect" > does not exist. Then, the first time you exit Convey, the ".convey/" > directory is created and ".connect" is written to. > > Check to make sure this is working properly to you USER home. > > Andy > > -----Original Message----- > From: con...@li... > [mailto:con...@li...]On Behalf Of eD > Braunhut > Sent: Thursday, July 31, 2003 12:08 PM > To: con...@li... > Subject: Re: [convey-developers] convey 0.3 > > > Cool Andy, > I can't check it out because I'm getting no response to cvs update. > Perhaps the server is down? Don't know... I'm working on the tab pane > close functionality right now. I'll let ya know when I'm done. > Ed > > On Thursday, July 31, 2003, at 11:36 AM, Andy Ames wrote: > >> Check out the new Convey 0.3. >> >> This means you, too, Ed. I added some functionality that we talked >> about. >> There is a single Convey window now, that allows you to connect, >> disconnect, >> start chats, and do chats. >> >> Also, the connect dialog box saves previous values in drop down combo >> boxes. >> >> Andy >> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by: Free pre-built ASP.NET sites including >> Data Reports, E-commerce, Portals, and Forums are available now. >> Download today and enter to win an XBOX or Visual Studio .NET. >> http://aspnet.click-url.com/go/psa00100003ave/ >> direct;at.aspnet_072303_01/01 >> _______________________________________________ >> convey-developers mailing list >> con...@li... >> https://lists.sourceforge.net/lists/listinfo/convey-developers >> > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers > |
|
From: eD B. <edb...@ca...> - 2003-07-31 20:43:02
|
There...it's done. Check it out. Ed On Thursday, July 31, 2003, at 01:12 PM, Andy Ames wrote: > The CVS server is working on my end. > > Try again. > > One thing to look for when you get Convey updated, in your HOME dir, a > configuration directory is created called ".convey/". In this > directory, a > file is created called ".connect" > > This file stores the contents of the ConnectDialog. The first time you > run > Convey, default contents are placed in the ConnectDialog because > ".connect" > does not exist. Then, the first time you exit Convey, the ".convey/" > directory is created and ".connect" is written to. > > Check to make sure this is working properly to you USER home. > > Andy > > -----Original Message----- > From: con...@li... > [mailto:con...@li...]On Behalf Of eD > Braunhut > Sent: Thursday, July 31, 2003 12:08 PM > To: con...@li... > Subject: Re: [convey-developers] convey 0.3 > > > Cool Andy, > I can't check it out because I'm getting no response to cvs update. > Perhaps the server is down? Don't know... I'm working on the tab pane > close functionality right now. I'll let ya know when I'm done. > Ed > > On Thursday, July 31, 2003, at 11:36 AM, Andy Ames wrote: > >> Check out the new Convey 0.3. >> >> This means you, too, Ed. I added some functionality that we talked >> about. >> There is a single Convey window now, that allows you to connect, >> disconnect, >> start chats, and do chats. >> >> Also, the connect dialog box saves previous values in drop down combo >> boxes. >> >> Andy >> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by: Free pre-built ASP.NET sites including >> Data Reports, E-commerce, Portals, and Forums are available now. >> Download today and enter to win an XBOX or Visual Studio .NET. >> http://aspnet.click-url.com/go/psa00100003ave/ >> direct;at.aspnet_072303_01/01 >> _______________________________________________ >> convey-developers mailing list >> con...@li... >> https://lists.sourceforge.net/lists/listinfo/convey-developers >> > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers > |
|
From: Andy A. <ag...@sb...> - 2003-07-31 20:22:51
|
The CVS server is working on my end. Try again. One thing to look for when you get Convey updated, in your HOME dir, a configuration directory is created called ".convey/". In this directory, a file is created called ".connect" This file stores the contents of the ConnectDialog. The first time you run Convey, default contents are placed in the ConnectDialog because ".connect" does not exist. Then, the first time you exit Convey, the ".convey/" directory is created and ".connect" is written to. Check to make sure this is working properly to you USER home. Andy -----Original Message----- From: con...@li... [mailto:con...@li...]On Behalf Of eD Braunhut Sent: Thursday, July 31, 2003 12:08 PM To: con...@li... Subject: Re: [convey-developers] convey 0.3 Cool Andy, I can't check it out because I'm getting no response to cvs update. Perhaps the server is down? Don't know... I'm working on the tab pane close functionality right now. I'll let ya know when I'm done. Ed On Thursday, July 31, 2003, at 11:36 AM, Andy Ames wrote: > Check out the new Convey 0.3. > > This means you, too, Ed. I added some functionality that we talked > about. > There is a single Convey window now, that allows you to connect, > disconnect, > start chats, and do chats. > > Also, the connect dialog box saves previous values in drop down combo > boxes. > > Andy > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers > ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ convey-developers mailing list con...@li... https://lists.sourceforge.net/lists/listinfo/convey-developers |
|
From: eD B. <edb...@ca...> - 2003-07-31 19:05:55
|
Cool Andy, I can't check it out because I'm getting no response to cvs update. Perhaps the server is down? Don't know... I'm working on the tab pane close functionality right now. I'll let ya know when I'm done. Ed On Thursday, July 31, 2003, at 11:36 AM, Andy Ames wrote: > Check out the new Convey 0.3. > > This means you, too, Ed. I added some functionality that we talked > about. > There is a single Convey window now, that allows you to connect, > disconnect, > start chats, and do chats. > > Also, the connect dialog box saves previous values in drop down combo > boxes. > > Andy > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers > |
|
From: Andy A. <ag...@sb...> - 2003-07-31 18:37:08
|
Check out the new Convey 0.3. This means you, too, Ed. I added some functionality that we talked about. There is a single Convey window now, that allows you to connect, disconnect, start chats, and do chats. Also, the connect dialog box saves previous values in drop down combo boxes. Andy |
|
From: Scott L. <sco...@ho...> - 2003-07-30 19:59:34
|
Oops. Correction on last email regarding size of "action-goto" table: S x (N
+ T)
It is interesting to note that a LL(1) parser can also be expressed as a
transition table -- its size is T x N.
>From: "Scott Luan" <sco...@ho...>
>Reply-To: con...@li...
>To: con...@li...
>Subject: RE: [convey-developers] XML parser
>Date: Wed, 30 Jul 2003 12:52:43 -0700
>
>Andy,
>
>>So, you're saying that a hand written parser (as I described) is an LL(k)
>>parser?
>
>Yes. The first "L" means you scan the input from left to right. The
>second "L" means you create a leftmost derivation. Therefore, the "R" in LR
>means creating a rightmost derivation. There are different types of LR
>parsers: LR(k), simple LR(k) or SLR(k), and lookaheah LR(k) or LALR(k).
>
>>Writing a LALR(1) parser by hand would require us to design the state
>>machine.
>
>That's right. The state machine is captured in an "action-goto" table
>which specifies when to shift tokens from the input and when to reduce to
>non-terminals given production rules. This table is generated by
>yacc/bison and has a size of S x N x T, where S, N, T are the number of
>states, non-terminals, and terminals, respectively. The number of states
>depend on the production rules and can be exponential in the worse case.
>
>I like this book:
>_Compilers: Principles, Techniques, and Tools_ by Alfred V. Aho, et al
>
>Scott
>
>>From: "Andy Ames" <ag...@sb...>
>>Reply-To: con...@li...
>>To: <con...@li...>
>>Subject: RE: [convey-developers] XML parser
>>Date: Wed, 30 Jul 2003 11:27:51 -0700
>>
>>Scott,
>>
>>Comments embedded...
>>
>>-----Original Message-----
>>From: con...@li...
>>[mailto:con...@li...]On Behalf Of Scott
>>Luan
>>Sent: Wednesday, July 30, 2003 12:16 AM
>>To: con...@li...
>>Subject: Re: [convey-developers] XML parser
>>
>>
>>Hi Andy,
>>
>>Great!
>>
>>Here are some remarks to your previous email:
>>
>>(1) I believe you meant LL(k) instead of LALR(k). LL is a top-down
>>("recursive descent") approach which tries to predict the production by
>>looking ahead, where, as you said, k is the number of tokens to look
>>ahead.
>>LALR is a bottom-up approach in which the parser, in a matter of speaking,
>>keeps open the possibility that a production may be valid by using a state
>>stack. yacc uses LALR(1). bison, an updated version of yacc, provides
>>the
>>option to use a generalized version of LALR called GLR - G for
>>generalized
>>- in which ambiguities are explored by parallel "threads" which die when
>>they enounter conflicts. The XML productions you listed can be parsed by
>>LALR(1) and LL(6) but not LL(1).
>>
>>So, you're saying that a hand written parser (as I described) is an LL(k)
>>parser?
>>
>>Writing a LALR(1) parser by hand would require us to design the state
>>machine.
>>
>>(2) expat, a xml parser, is much more lightweight compared to Xerces. It
>>is
>>written in C and is fast.
>>What are your requirements? (i.e. performance, memory usage, footprint)
>>
>>http://expat.sourceforge.net/
>>
>>other available parsers are listed at
>>http://www.garshol.priv.no/download/xmltools/plat_ix.html#plat9
>>
>>expat looks good. It's exactly the level I was looking for regarding
>>performance and footprint.
>>
>>(3) Yes, XML is difficult to parse using tools like lex/flex/yacc/bison
>>for
>>many reasons. One of the more fundamental reasons may relate to the fact
>>that a XML document cannot be described by a context free grammar (since
>>the
>>grammar of the XML document is itself defined by a DTD). CFG's include
>>LL(k) and *LR grammars. We may write a parser which applies to a given
>>DTD
>>(i.e. CFG)... but I have to dwell on this one for a bit because
>>difficulties
>>may arise when dealing with delimiters, entities, and element hierarchies.
>>More thoughts on this later....
>>
>>Apparently, It is possible to write a XML parser using existing tools that
>>does not perform validation. It would only ensure the document is
>>well-formed, though. Like you said, it cannot verify the document is valid
>>with respect to a DTD.
>>
>>(4) From my understanding, the DOM model strives to contain all
>>information
>>within the DOM tree. This may be a preferrable abstraction compared to
>>SAX.
>> However, the tradeoff is, of course, performance and memory usage.
>>
>>We have a DOM implementation. That's the wxxml module. The parser is used
>>to
>>read a document and build the DOM recursively.
>>
>>Thanks for your input. I read a short tutorial on expat and I'll give it a
>>try.
>>
>>Andy
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>>Data Reports, E-commerce, Portals, and Forums are available now.
>>Download today and enter to win an XBOX or Visual Studio .NET.
>>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>>_______________________________________________
>>convey-developers mailing list
>>con...@li...
>>https://lists.sourceforge.net/lists/listinfo/convey-developers
>
>_________________________________________________________________
>The new MSN 8: advanced junk mail protection and 2 months FREE*
>http://join.msn.com/?page=features/junkmail
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>convey-developers mailing list
>con...@li...
>https://lists.sourceforge.net/lists/listinfo/convey-developers
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
|
|
From: Scott L. <sco...@ho...> - 2003-07-30 19:52:51
|
Andy,
>So, you're saying that a hand written parser (as I described) is an LL(k)
>parser?
Yes. The first "L" means you scan the input from left to right. The second
"L" means you create a leftmost derivation. Therefore, the "R" in LR means
creating a rightmost derivation. There are different types of LR parsers:
LR(k), simple LR(k) or SLR(k), and lookaheah LR(k) or LALR(k).
>Writing a LALR(1) parser by hand would require us to design the state
>machine.
That's right. The state machine is captured in an "action-goto" table which
specifies when to shift tokens from the input and when to reduce to
non-terminals given production rules. This table is generated by yacc/bison
and has a size of S x N x T, where S, N, T are the number of states,
non-terminals, and terminals, respectively. The number of states depend on
the production rules and can be exponential in the worse case.
I like this book:
_Compilers: Principles, Techniques, and Tools_ by Alfred V. Aho, et al
Scott
>From: "Andy Ames" <ag...@sb...>
>Reply-To: con...@li...
>To: <con...@li...>
>Subject: RE: [convey-developers] XML parser
>Date: Wed, 30 Jul 2003 11:27:51 -0700
>
>Scott,
>
>Comments embedded...
>
>-----Original Message-----
>From: con...@li...
>[mailto:con...@li...]On Behalf Of Scott
>Luan
>Sent: Wednesday, July 30, 2003 12:16 AM
>To: con...@li...
>Subject: Re: [convey-developers] XML parser
>
>
>Hi Andy,
>
>Great!
>
>Here are some remarks to your previous email:
>
>(1) I believe you meant LL(k) instead of LALR(k). LL is a top-down
>("recursive descent") approach which tries to predict the production by
>looking ahead, where, as you said, k is the number of tokens to look ahead.
>LALR is a bottom-up approach in which the parser, in a matter of speaking,
>keeps open the possibility that a production may be valid by using a state
>stack. yacc uses LALR(1). bison, an updated version of yacc, provides the
>option to use a generalized version of LALR called GLR - G for generalized
>- in which ambiguities are explored by parallel "threads" which die when
>they enounter conflicts. The XML productions you listed can be parsed by
>LALR(1) and LL(6) but not LL(1).
>
>So, you're saying that a hand written parser (as I described) is an LL(k)
>parser?
>
>Writing a LALR(1) parser by hand would require us to design the state
>machine.
>
>(2) expat, a xml parser, is much more lightweight compared to Xerces. It
>is
>written in C and is fast.
>What are your requirements? (i.e. performance, memory usage, footprint)
>
>http://expat.sourceforge.net/
>
>other available parsers are listed at
>http://www.garshol.priv.no/download/xmltools/plat_ix.html#plat9
>
>expat looks good. It's exactly the level I was looking for regarding
>performance and footprint.
>
>(3) Yes, XML is difficult to parse using tools like lex/flex/yacc/bison for
>many reasons. One of the more fundamental reasons may relate to the fact
>that a XML document cannot be described by a context free grammar (since
>the
>grammar of the XML document is itself defined by a DTD). CFG's include
>LL(k) and *LR grammars. We may write a parser which applies to a given DTD
>(i.e. CFG)... but I have to dwell on this one for a bit because
>difficulties
>may arise when dealing with delimiters, entities, and element hierarchies.
>More thoughts on this later....
>
>Apparently, It is possible to write a XML parser using existing tools that
>does not perform validation. It would only ensure the document is
>well-formed, though. Like you said, it cannot verify the document is valid
>with respect to a DTD.
>
>(4) From my understanding, the DOM model strives to contain all information
>within the DOM tree. This may be a preferrable abstraction compared to
>SAX.
> However, the tradeoff is, of course, performance and memory usage.
>
>We have a DOM implementation. That's the wxxml module. The parser is used
>to
>read a document and build the DOM recursively.
>
>Thanks for your input. I read a short tutorial on expat and I'll give it a
>try.
>
>Andy
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>convey-developers mailing list
>con...@li...
>https://lists.sourceforge.net/lists/listinfo/convey-developers
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
|
|
From: eD B. <edb...@ca...> - 2003-07-30 19:46:19
|
Scott, expat looks pretty good. I read the article on it at www.xml.com written awhile back (1999). I would say that speed is one of the most important factors when using coordinating activity over a network with transactions. According to the article, 80% of it's functionality is based on 4 functions. Also, it can deal with US-ASCII encodings which is what wxXml is currently limited to. What do you think, Andy? > (2) expat, a xml parser, is much more lightweight compared to Xerces. > It is written in C and is fast. > What are your requirements? (i.e. performance, memory usage, footprint) > > http://expat.sourceforge.net/ > > other available parsers are listed at > http://www.garshol.priv.no/download/xmltools/plat_ix.html#plat9 > > (3) Yes, XML is difficult to parse using tools like > lex/flex/yacc/bison for many reasons. One of the more fundamental > reasons may relate to the fact that a XML document cannot be described > by a context free grammar (since the grammar of the XML document is > itself defined by a DTD). CFG's include LL(k) and *LR grammars. We > may write a parser which applies to a given DTD (i.e. CFG)... but I > have to dwell on this one for a bit because difficulties may arise > when dealing with delimiters, entities, and element hierarchies. More > thoughts on this later.... > > (4) From my understanding, the DOM model strives to contain all > information within the DOM tree. This may be a preferrable > abstraction compared to SAX. However, the tradeoff is, of course, > performance and memory usage. > > Scott > >> From: "Andy Ames" <ag...@sb...> >> Reply-To: con...@li... >> To: <con...@li...> >> Subject: [convey-developers] XML parser >> Date: Tue, 29 Jul 2003 02:56:50 -0700 >> >> Hi, again. >> >> The wxxml API is just about finished. The inputter has been >> implemented. XML >> content may be read from a file or stream and parsed into a document >> object >> structure, and vice versa. >> >> There is one last task to do. Write our own parser. Currently, it >> uses the >> Xerces C++ SAX 2 implementation. This is a fairly standard >> implementation >> for web servers, but it is very heavyweight. >> >> I used Xerces so I could bootstrap us a working implementation. >> >> I'm going to throw this out for either of you (Scott and Ed), in case >> you're >> interested enough to put some time into this. Scott, this is relevant >> to the >> class you've been taking and I believe both of you'd find this >> fascinating. >> >> We need to write a parser for the XML language by hand. Using scanner >> and >> parser generators like flex and bison wouldn't give us an efficient >> implementation for a couple reasons: >> >> 1) XML "tokens" are difficult, if not impossible to describe using a >> regular >> language, >> >> 2) entity replacements (< and so on) would be difficult to >> describe using >> a grammar, and >> >> 3) using a standard parser generator will not automatically optimize >> the >> special cases. >> >> Another important reason why a hand-written XML parser would be >> easier, is >> that we could write it as a LALR(k) parser. The XML spec is LALR(k), >> where k >> > 1 for many productions. For examples, the Element production looks >> like >> this: >> >> [39] Element ::= EmptyElemTag | Stag Content ETag >> [40] STag ::= '<' Name (S Attribute)* S? '>' >> [42] ETag ::= '</' Name S? '>' >> [44] EmptyElemTag ::= '<' Name (S Attribute)* S? '/>' >> >> When a parser comes across a XML element such as "<beer/>" or >> "<beer>My >> Favorite</beer>", the parser does not know what production it is >> working on, >> 40 or 44, until it sees the '/' or '>' at the end. This production >> alone >> makes XML LALR(6), if you count the tokens on the right side of >> production >> 40. >> >> Of course, we could regroup the production tokens to give us LALR(1). >> However, doing so will increase the number of productions. >> >> The XML spec has 83 productions. The productions regarding DTDs, we >> can >> ignore at first, because Jabber XML streams doesn't need them. This >> drops us >> to around 50 productions. >> >> To write a parser by hand, that means we have 50 functions in a >> single class >> to write. Here's the idea: >> >> Assumption - We have a buffered character stream with unlimited >> pushback and >> look-ahead. The stream gives us the following methods: >> >> bool Match(char c) - matches a single character in the stream, >> returning >> true, if the next character in the stream is c; false, otherwise. If >> match, >> the current stream position advances 1. >> >> bool Match(wxString str) - matches a string of characters in the >> stream, >> returning true, if every character matches; false, otherwise. If >> match, the >> current stream position advances str.Length(). >> >> char Peek(int i) - returns the character in the stream that is i >> positions >> from the current position. >> >> char Get() - returns the next character in the stream and advances the >> stream position by 1. >> >> void PushBack(int i) - pushes the stream position back i positions. >> >> Here would be some functions we would write to parse a document: >> >> [1] Document ::= Prolog Element Misc* >> >> bool Document() { >> if(!Prolog()) >> return false; >> >> if(!Element()) >> return false; >> >> while(Misc()); >> >> return true; >> } >> >> [3] S ::= (#x20 | #x9 | #xD | #xA)+ // whitespace >> >> bool S() { >> if(Peek(0) == 0x20 || Peek(0) == 0x09 || >> Peek(0) == 0x0D || Peek(0) == 0x0A) >> Get(); >> else >> return false; >> >> while(Peek(0) == 0x20 || Peek(0) == 0x09 || >> Peek(0) == 0x0D || Peek(0) == 0x0A) >> Get(); >> >> return true; >> } >> >> [40] STag ::= '<' Name (S Attribute)* S? '>' >> >> bool STag() { >> if(!Match('<')) >> return false; >> >> Name(); >> >> if(!S() || !Attribute()) >> return false; >> >> while(S() && Attribute()); >> >> if(!Match('>')) >> return false; >> >> return true; >> } >> >> And so on, and so on... >> >> 50 or so of these functions. I have the buffered input stream setup >> for >> this, now I just need a few programmers to take a few dozen >> productions. >> >> What do you guys say? Scott, I know you said you'd be out of >> commission >> until the fall, so if you don't have cycles to throw at this, I >> understand. >> >> Ed? >> >> Andy >> >> >> >> ------------------------------------------------------- >> This SF.Net email sponsored by: Free pre-built ASP.NET sites including >> Data Reports, E-commerce, Portals, and Forums are available now. >> Download today and enter to win an XBOX or Visual Studio .NET. >> http://aspnet.click-url.com/go/psa00100003ave/ >> direct;at.aspnet_072303_01/01 >> _______________________________________________ >> convey-developers mailing list >> con...@li... >> https://lists.sourceforge.net/lists/listinfo/convey-developers > > _________________________________________________________________ > MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. > http://join.msn.com/?page=features/virus > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/ > direct;at.aspnet_072303_01/01 > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers > |
1 message has been excluded from this view by a project administrator.
