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: Andy A. <ag...@sb...> - 2003-10-13 21:57:27
|
Hi,
Good work. So libxmldiff is an existing library?
As for STL/wxWindows, there seems to be a lot of people having problems
using them together. In fact, a guy I work with has been trying to mix them
unsuccessfully. I haven't myself researched the problem at all.
I would say alternate option (2) is more ideal. In general, the wxWindows
container classes have been built to mimic STL to a certain degree. So
translations of basic STL use to wxWindows should be trivial. I've seen it
discussed somewhere in their documentation.
Andy
-----Original Message-----
From: con...@li...
[mailto:con...@li...]On Behalf Of Scott
Luan
Sent: Friday, October 10, 2003 3:55 PM
To: con...@li...
Subject: [convey-developers] wxWiindows and STL
Hello Andy, Ed.
Hope things are good.
Well, I've been working on getting somthing that would compute XML diff's
for Convey-- this past week. So far, it works fairly well with expat,
although with some modifications to the expat source (icky, but necessary).
Furthermore, xmldiff (let's call it that, for the sake of convienence)
produces dfff information in concise DUL (delta update language) in addition
to an alternative output format (which is processing instructions embedded
in the XML tree/document). DUL will allow us to minimize the bytes sent
across the network.
Ideally, I would like to have xmldiff to be a library with an API such as
XDiff xdiff(input1, input2, delta);
where the arguments may be an XML file, a root element, or a document
object, as below:
XmlDiffDocHandle *input1 = new XmlDiffDocHandle("doc1.xml");
wxXmlElement *rootNode;
wxXmlDocument *deltaDoc;
XmlDiffDocHandle *input2 = new XmlDiffDocHandle(rootNode);
XmlDiffDocHandle *delta = new XmlDiffDocHandle(deltaDoc);
Furthermore, XDiffUpdate update(document, delta, output) updates "document"
with "delta" and saves the result in "output" if it is not NULL, otherwise
"document" would be modified. "delta" may be NULL to signify that
"document" has processing instructions.
As you would expect, since we are using wxWindows, libxmldiff.a needs to be
compatible with this framework. I was hoping to retain the use of STL
containers and algorithms by using some tricks listed in the wxWindows
documentation. Specifically, there are two things I am doing;
(1) include the directives below before including any STL headers.
#ifdef new
#undef new
#endif
(2) set the following definitions (or some variant of such):
#define wxUSE_GLOBAL_MEMORY_OPERATORS 0
#define wxUSE_IOSTREAMH 0
#define wxUSE_DEBUG_CONTEXT 0
#define wxUSE_MEMORY_TRACING 0
#define wxUSE_DEBUG_NEW_ALWAYS 0
#define wxUSE_STD_IOSTREAM 1
However, I have not yet had any success in building xmldiff so that it uses
wxWindows classes AND STL containers/algorithms. An example of compilation
errors follows:
XLut.o: In function `_Hashtable_node<pair<unsigned int const, unsigned long
long> > * * __copy_trivial<_Hashtable_node<pair<unsigned int const, unsigned
long long> > *>(_Hashtable_node<pair<unsigned int const, unsigned long long>
> * const *, _Hashtable_node<pair<unsigned int const, unsigned long long> >
* const *, _Hashtable_node<pair<unsigned int const, unsigned long long> > *
*)':
/usr/lib/gcc-lib/i386-slackware-linux/2.95.3/../../../../include/g++-3/stl_v
ector.h(.__malloc_alloc_template<0>::gnu.linkonce.t._S_oom_malloc(unsigned
int)+0x1a): undefined reference to `endl(ostream &)'
Perhaps there is another way to do this? I hope so because the alternatives
(below) are less appealing:
(1) Fork xmldiff as a child process which only operates on files. File I/O
and starting a new process may be expensive.
(2) Convert STL templates to wxWindows classes. This may be possible, but
tedious.
Surprisingly, there are not too many discussions about this problem on the
internet. Perhaps you or your colleagues have encountered/resolved this
problem before? Otherwise, I'll keep tweeking until I resign myself to one
of the two options above.
Thanks,
Scott
>From: "Scott Luan" <sco...@ho...>
>Reply-To: con...@li...
>To: con...@li...
>Subject: [convey-developers] makefiles and etc
>Date: Wed, 01 Oct 2003 22:05:58 -0700
>
>Hello Andy,
>
>Thanks for the clarification. I see what you mean about the top-level
>makefile. autoconf or some such would be a nice touch. A simple
>alternative would be to have the top-level makefile test for the existence
>of various directories, and build the binaries as appropriate. This way
>there is a method of building several components with one command at the
>top-level, rather than manually invoking make at each subdirectory. This
>method may be used for those who have checked-out only a portion of the
>source tree (i.e. wxxml, wxjab but not convey). The only requirement is
>that the source tree structure does not change. Note that each
>subdirectory contains a makefile that is self-sufficient -- that is, wxxml
>and wxjab my be checked-out and built independently.
>
>Just to get sync-ed up with you guys, here's a list of what I will be
>working on for the next few weeks (in between moving, an OS class, and
>etc).
>
>1. Adapt an existing xml diff program to use expat. The author's paper is
>quite helpful: "X-Diff: An Effective Change Detection Algorithm for XML
>Documents." If you like, we can discuss some limitations of his algorithm
>and how it would impact convey. If you have a better alternative, please
>let me know. You may find more information at:
>http://www.cs.wisc.edu/~yuanwang/xdiff.html
>
>2. Write client code for NTP time sync. We should also leave this open to
>discussion, as NTP may possibly be too hefty for our purposes. We may have
>to investigate ways to time sync via TCP.
>
>3. And of course, the makefiles.
>
>Hope the quarter is going well for you guys.
>
>Regards,
>Scott
>
>
>>From: "Andy Ames" <ag...@sb...>
>>Reply-To: con...@li...
>>To: <con...@li...>
>>Subject: RE: [convey-developers] convey 0.4?
>>Date: Sat, 27 Sep 2003 16:38:58 -0700
>>
>>Scott,
>>
>>-----Original Message-----
>>From: con...@li...
>>[mailto:con...@li...]On Behalf Of Scott
>>Luan
>>Sent: Saturday, September 27, 2003 12:56 PM
>>To: con...@li...
>>Subject: RE: [convey-developers] convey 0.4?
>>
>>
>>Hello Andy,
>>
>>Thanks for the info.
>>
>>(1) The error generated while making wxjab.o is listed below:
>>
>>In file included from wxjab.cpp:1:
>>../../wxjab/include/wxjab.h:112: parse error before `,'
>>../../wxjab/include/wxjab.h:112: stray '\' in program
>>../../wxjab/include/wxjab.h:113: stray '\' in program
>>../../wxjab/include/wxjab.h:114: stray '\' in program
>>../../wxjab/include/wxjab.h:115: stray '\' in program
>>
>>This is the macro definition in wxjab.h:
>>#define EVT_JABBER_MESSAGE(id, func) \
>>
>> DECLARE_EVENT_TABLE_ENTRY(wxEVT_JABBER_MESSAGE, id, -1, \
>>
>> (wxObjectEventFunction) \
>>
>> (wxEventFunction) \
>>
>> (wxJabberMessageEventFunction) & func, \
>>
>> (wxObject *) NULL ),<--- ends here.
>>
>>Note that this macro is not used anywhere.
>>
>><andy>Sweet.</andy>
>>
>>(2) The build error for wxjab, I discovered, is due to a mistaken identity
>>in the header files. Specifically testapp.h for both wxxml and wxjab.
>>
>><andy>Perhaps they should be renamed to testxml and testjab, or
>>something.</andy>
>>
>>(3) I am not sure if we decided to include the makefiles in the source
>>tree.
>> I think it is a good idea so that we can all use the same build
>>process.
>>But.. there may be incompatibilities with MS' nmake. Hmmm... Well,
>>perhaps
>>we just have to sync up manually and accept the amusing fact that we are
>>using 4 platforms among 3 people! :-) Well, if we have decided to
>>include
>>the makefiles, I don't believe I can create/checkin any files in any
>>directory other than wxjab. Perhaps for the sake of convienence, the
>>adminstrative demands may be relaxed for this informal group of fun-loving
>>developers. :-)
>>
>><andy>You can't checkin files? Hmmm. I'll look into it and give you
>>permissions for the whole source tree.
>>Makefiles are definately good. This will allow us to synch up Mac OS X,
>>Linux, Solaris, and the like. I definately think we should have them. I
>>also
>>would like to have MSVC and Project Builder projects for GUI debugging. Of
>>course, it is difficult to keep them synched with Makefiles. In practice,
>>the GUI project builds usually breakdown more frequently. That's okay,
>>though.
>>
>>Makefiles with Windows are almost never compatible with 'nixes for many
>>reasons, so I don't even care to try. That was a plus with Java. You could
>>better streamline the build systems between OSes. However, in practice, in
>>didn't always work.</andy>
>>
>>(4) >can we provide a way to indicate to the wxjab build system where it
>>can find the wxxml library.
>>yes, we can use the -L switch for the linker
>>
>><andy>What I mean is by using some kind of configure or autoconf
>>mechanism.
>>The reason is that I'd like wxxml and wxjab to be as separate as possible.
>>I
>>was thinking this because the wxxml module can be checked out and built
>>separate from the wxjab module. I'd like to keep it that way.
>>
>>(At UCSC, we're using the wxxml module to do...well, XML stuff. We don't
>>need wxjab.)
>>
>>This is also why I wasn't thinking we'd have a top-level Makefile.
>>
>>What are your thoughts on this? If someone were to check out only the
>>wxxml
>>module, then they wouldn't get the top-level Makefile anyway. Right? What
>>about if they only checked out the wxxml and wxjab modules, but not
>>convey?
>>
>>Hopefully this gives you an idea of my thinking. I guess I would like a
>>top-level Makefile as long as it can detect which modules have been
>>checked
>>out and only build those. Should it also build Convey Java?</andy>
>>
>>(5) >I'd prefer not to have to place a top-level convey Makefile in the
>>repository.
>>Having a makefile in the top-level directory will allow a recursive build
>>process which is convienent to automate the entire build.
>>
>>That's all for now. Enjoy your weekends.
>>
>>Andy
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>convey-developers mailing list
>>con...@li...
>>https://lists.sourceforge.net/lists/listinfo/convey-developers
>
>_________________________________________________________________
>Share your photos without swamping your Inbox. Get Hotmail Extra Storage
>today! http://join.msn.com/?PAGE=features/es
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>convey-developers mailing list
>con...@li...
>https://lists.sourceforge.net/lists/listinfo/convey-developers
_________________________________________________________________
Share your photos without swamping your Inbox. Get Hotmail Extra Storage
today! http://join.msn.com/?PAGE=features/es
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
convey-developers mailing list
con...@li...
https://lists.sourceforge.net/lists/listinfo/convey-developers
|
|
From: Scott L. <sco...@ho...> - 2003-10-10 22:55:33
|
Hello Andy, Ed.
Hope things are good.
Well, I've been working on getting somthing that would compute XML diff's
for Convey-- this past week. So far, it works fairly well with expat,
although with some modifications to the expat source (icky, but necessary).
Furthermore, xmldiff (let's call it that, for the sake of convienence)
produces dfff information in concise DUL (delta update language) in addition
to an alternative output format (which is processing instructions embedded
in the XML tree/document). DUL will allow us to minimize the bytes sent
across the network.
Ideally, I would like to have xmldiff to be a library with an API such as
XDiff xdiff(input1, input2, delta);
where the arguments may be an XML file, a root element, or a document
object, as below:
XmlDiffDocHandle *input1 = new XmlDiffDocHandle("doc1.xml");
wxXmlElement *rootNode;
wxXmlDocument *deltaDoc;
XmlDiffDocHandle *input2 = new XmlDiffDocHandle(rootNode);
XmlDiffDocHandle *delta = new XmlDiffDocHandle(deltaDoc);
Furthermore, XDiffUpdate update(document, delta, output) updates "document"
with "delta" and saves the result in "output" if it is not NULL, otherwise
"document" would be modified. "delta" may be NULL to signify that
"document" has processing instructions.
As you would expect, since we are using wxWindows, libxmldiff.a needs to be
compatible with this framework. I was hoping to retain the use of STL
containers and algorithms by using some tricks listed in the wxWindows
documentation. Specifically, there are two things I am doing;
(1) include the directives below before including any STL headers.
#ifdef new
#undef new
#endif
(2) set the following definitions (or some variant of such):
#define wxUSE_GLOBAL_MEMORY_OPERATORS 0
#define wxUSE_IOSTREAMH 0
#define wxUSE_DEBUG_CONTEXT 0
#define wxUSE_MEMORY_TRACING 0
#define wxUSE_DEBUG_NEW_ALWAYS 0
#define wxUSE_STD_IOSTREAM 1
However, I have not yet had any success in building xmldiff so that it uses
wxWindows classes AND STL containers/algorithms. An example of compilation
errors follows:
XLut.o: In function `_Hashtable_node<pair<unsigned int const, unsigned long
long> > * * __copy_trivial<_Hashtable_node<pair<unsigned int const, unsigned
long long> > *>(_Hashtable_node<pair<unsigned int const, unsigned long long>
> * const *, _Hashtable_node<pair<unsigned int const, unsigned long long> >
* const *, _Hashtable_node<pair<unsigned int const, unsigned long long> > *
*)':
/usr/lib/gcc-lib/i386-slackware-linux/2.95.3/../../../../include/g++-3/stl_vector.h(.__malloc_alloc_template<0>::gnu.linkonce.t._S_oom_malloc(unsigned
int)+0x1a): undefined reference to `endl(ostream &)'
Perhaps there is another way to do this? I hope so because the alternatives
(below) are less appealing:
(1) Fork xmldiff as a child process which only operates on files. File I/O
and starting a new process may be expensive.
(2) Convert STL templates to wxWindows classes. This may be possible, but
tedious.
Surprisingly, there are not too many discussions about this problem on the
internet. Perhaps you or your colleagues have encountered/resolved this
problem before? Otherwise, I'll keep tweeking until I resign myself to one
of the two options above.
Thanks,
Scott
>From: "Scott Luan" <sco...@ho...>
>Reply-To: con...@li...
>To: con...@li...
>Subject: [convey-developers] makefiles and etc
>Date: Wed, 01 Oct 2003 22:05:58 -0700
>
>Hello Andy,
>
>Thanks for the clarification. I see what you mean about the top-level
>makefile. autoconf or some such would be a nice touch. A simple
>alternative would be to have the top-level makefile test for the existence
>of various directories, and build the binaries as appropriate. This way
>there is a method of building several components with one command at the
>top-level, rather than manually invoking make at each subdirectory. This
>method may be used for those who have checked-out only a portion of the
>source tree (i.e. wxxml, wxjab but not convey). The only requirement is
>that the source tree structure does not change. Note that each
>subdirectory contains a makefile that is self-sufficient -- that is, wxxml
>and wxjab my be checked-out and built independently.
>
>Just to get sync-ed up with you guys, here's a list of what I will be
>working on for the next few weeks (in between moving, an OS class, and
>etc).
>
>1. Adapt an existing xml diff program to use expat. The author's paper is
>quite helpful: "X-Diff: An Effective Change Detection Algorithm for XML
>Documents." If you like, we can discuss some limitations of his algorithm
>and how it would impact convey. If you have a better alternative, please
>let me know. You may find more information at:
>http://www.cs.wisc.edu/~yuanwang/xdiff.html
>
>2. Write client code for NTP time sync. We should also leave this open to
>discussion, as NTP may possibly be too hefty for our purposes. We may have
>to investigate ways to time sync via TCP.
>
>3. And of course, the makefiles.
>
>Hope the quarter is going well for you guys.
>
>Regards,
>Scott
>
>
>>From: "Andy Ames" <ag...@sb...>
>>Reply-To: con...@li...
>>To: <con...@li...>
>>Subject: RE: [convey-developers] convey 0.4?
>>Date: Sat, 27 Sep 2003 16:38:58 -0700
>>
>>Scott,
>>
>>-----Original Message-----
>>From: con...@li...
>>[mailto:con...@li...]On Behalf Of Scott
>>Luan
>>Sent: Saturday, September 27, 2003 12:56 PM
>>To: con...@li...
>>Subject: RE: [convey-developers] convey 0.4?
>>
>>
>>Hello Andy,
>>
>>Thanks for the info.
>>
>>(1) The error generated while making wxjab.o is listed below:
>>
>>In file included from wxjab.cpp:1:
>>../../wxjab/include/wxjab.h:112: parse error before `,'
>>../../wxjab/include/wxjab.h:112: stray '\' in program
>>../../wxjab/include/wxjab.h:113: stray '\' in program
>>../../wxjab/include/wxjab.h:114: stray '\' in program
>>../../wxjab/include/wxjab.h:115: stray '\' in program
>>
>>This is the macro definition in wxjab.h:
>>#define EVT_JABBER_MESSAGE(id, func) \
>>
>> DECLARE_EVENT_TABLE_ENTRY(wxEVT_JABBER_MESSAGE, id, -1, \
>>
>> (wxObjectEventFunction) \
>>
>> (wxEventFunction) \
>>
>> (wxJabberMessageEventFunction) & func, \
>>
>> (wxObject *) NULL ),<--- ends here.
>>
>>Note that this macro is not used anywhere.
>>
>><andy>Sweet.</andy>
>>
>>(2) The build error for wxjab, I discovered, is due to a mistaken identity
>>in the header files. Specifically testapp.h for both wxxml and wxjab.
>>
>><andy>Perhaps they should be renamed to testxml and testjab, or
>>something.</andy>
>>
>>(3) I am not sure if we decided to include the makefiles in the source
>>tree.
>> I think it is a good idea so that we can all use the same build
>>process.
>>But.. there may be incompatibilities with MS' nmake. Hmmm... Well,
>>perhaps
>>we just have to sync up manually and accept the amusing fact that we are
>>using 4 platforms among 3 people! :-) Well, if we have decided to
>>include
>>the makefiles, I don't believe I can create/checkin any files in any
>>directory other than wxjab. Perhaps for the sake of convienence, the
>>adminstrative demands may be relaxed for this informal group of fun-loving
>>developers. :-)
>>
>><andy>You can't checkin files? Hmmm. I'll look into it and give you
>>permissions for the whole source tree.
>>Makefiles are definately good. This will allow us to synch up Mac OS X,
>>Linux, Solaris, and the like. I definately think we should have them. I
>>also
>>would like to have MSVC and Project Builder projects for GUI debugging. Of
>>course, it is difficult to keep them synched with Makefiles. In practice,
>>the GUI project builds usually breakdown more frequently. That's okay,
>>though.
>>
>>Makefiles with Windows are almost never compatible with 'nixes for many
>>reasons, so I don't even care to try. That was a plus with Java. You could
>>better streamline the build systems between OSes. However, in practice, in
>>didn't always work.</andy>
>>
>>(4) >can we provide a way to indicate to the wxjab build system where it
>>can find the wxxml library.
>>yes, we can use the -L switch for the linker
>>
>><andy>What I mean is by using some kind of configure or autoconf
>>mechanism.
>>The reason is that I'd like wxxml and wxjab to be as separate as possible.
>>I
>>was thinking this because the wxxml module can be checked out and built
>>separate from the wxjab module. I'd like to keep it that way.
>>
>>(At UCSC, we're using the wxxml module to do...well, XML stuff. We don't
>>need wxjab.)
>>
>>This is also why I wasn't thinking we'd have a top-level Makefile.
>>
>>What are your thoughts on this? If someone were to check out only the
>>wxxml
>>module, then they wouldn't get the top-level Makefile anyway. Right? What
>>about if they only checked out the wxxml and wxjab modules, but not
>>convey?
>>
>>Hopefully this gives you an idea of my thinking. I guess I would like a
>>top-level Makefile as long as it can detect which modules have been
>>checked
>>out and only build those. Should it also build Convey Java?</andy>
>>
>>(5) >I'd prefer not to have to place a top-level convey Makefile in the
>>repository.
>>Having a makefile in the top-level directory will allow a recursive build
>>process which is convienent to automate the entire build.
>>
>>That's all for now. Enjoy your weekends.
>>
>>Andy
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>convey-developers mailing list
>>con...@li...
>>https://lists.sourceforge.net/lists/listinfo/convey-developers
>
>_________________________________________________________________
>Share your photos without swamping your Inbox. Get Hotmail Extra Storage
>today! http://join.msn.com/?PAGE=features/es
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>convey-developers mailing list
>con...@li...
>https://lists.sourceforge.net/lists/listinfo/convey-developers
_________________________________________________________________
Share your photos without swamping your Inbox. Get Hotmail Extra Storage
today! http://join.msn.com/?PAGE=features/es
|
|
From: Scott L. <sco...@ho...> - 2003-10-02 05:06:35
|
Hello Andy, Thanks for the clarification. I see what you mean about the top-level makefile. autoconf or some such would be a nice touch. A simple alternative would be to have the top-level makefile test for the existence of various directories, and build the binaries as appropriate. This way there is a method of building several components with one command at the top-level, rather than manually invoking make at each subdirectory. This method may be used for those who have checked-out only a portion of the source tree (i.e. wxxml, wxjab but not convey). The only requirement is that the source tree structure does not change. Note that each subdirectory contains a makefile that is self-sufficient -- that is, wxxml and wxjab my be checked-out and built independently. Just to get sync-ed up with you guys, here's a list of what I will be working on for the next few weeks (in between moving, an OS class, and etc). 1. Adapt an existing xml diff program to use expat. The author's paper is quite helpful: "X-Diff: An Effective Change Detection Algorithm for XML Documents." If you like, we can discuss some limitations of his algorithm and how it would impact convey. If you have a better alternative, please let me know. You may find more information at: http://www.cs.wisc.edu/~yuanwang/xdiff.html 2. Write client code for NTP time sync. We should also leave this open to discussion, as NTP may possibly be too hefty for our purposes. We may have to investigate ways to time sync via TCP. 3. And of course, the makefiles. Hope the quarter is going well for you guys. Regards, Scott >From: "Andy Ames" <ag...@sb...> >Reply-To: con...@li... >To: <con...@li...> >Subject: RE: [convey-developers] convey 0.4? >Date: Sat, 27 Sep 2003 16:38:58 -0700 > >Scott, > >-----Original Message----- >From: con...@li... >[mailto:con...@li...]On Behalf Of Scott >Luan >Sent: Saturday, September 27, 2003 12:56 PM >To: con...@li... >Subject: RE: [convey-developers] convey 0.4? > > >Hello Andy, > >Thanks for the info. > >(1) The error generated while making wxjab.o is listed below: > >In file included from wxjab.cpp:1: >../../wxjab/include/wxjab.h:112: parse error before `,' >../../wxjab/include/wxjab.h:112: stray '\' in program >../../wxjab/include/wxjab.h:113: stray '\' in program >../../wxjab/include/wxjab.h:114: stray '\' in program >../../wxjab/include/wxjab.h:115: stray '\' in program > >This is the macro definition in wxjab.h: >#define EVT_JABBER_MESSAGE(id, func) \ > > DECLARE_EVENT_TABLE_ENTRY(wxEVT_JABBER_MESSAGE, id, -1, \ > > (wxObjectEventFunction) \ > > (wxEventFunction) \ > > (wxJabberMessageEventFunction) & func, \ > > (wxObject *) NULL ),<--- ends here. > >Note that this macro is not used anywhere. > ><andy>Sweet.</andy> > >(2) The build error for wxjab, I discovered, is due to a mistaken identity >in the header files. Specifically testapp.h for both wxxml and wxjab. > ><andy>Perhaps they should be renamed to testxml and testjab, or >something.</andy> > >(3) I am not sure if we decided to include the makefiles in the source >tree. > I think it is a good idea so that we can all use the same build process. >But.. there may be incompatibilities with MS' nmake. Hmmm... Well, >perhaps >we just have to sync up manually and accept the amusing fact that we are >using 4 platforms among 3 people! :-) Well, if we have decided to include >the makefiles, I don't believe I can create/checkin any files in any >directory other than wxjab. Perhaps for the sake of convienence, the >adminstrative demands may be relaxed for this informal group of fun-loving >developers. :-) > ><andy>You can't checkin files? Hmmm. I'll look into it and give you >permissions for the whole source tree. >Makefiles are definately good. This will allow us to synch up Mac OS X, >Linux, Solaris, and the like. I definately think we should have them. I >also >would like to have MSVC and Project Builder projects for GUI debugging. Of >course, it is difficult to keep them synched with Makefiles. In practice, >the GUI project builds usually breakdown more frequently. That's okay, >though. > >Makefiles with Windows are almost never compatible with 'nixes for many >reasons, so I don't even care to try. That was a plus with Java. You could >better streamline the build systems between OSes. However, in practice, in >didn't always work.</andy> > >(4) >can we provide a way to indicate to the wxjab build system where it >can find the wxxml library. >yes, we can use the -L switch for the linker > ><andy>What I mean is by using some kind of configure or autoconf mechanism. >The reason is that I'd like wxxml and wxjab to be as separate as possible. >I >was thinking this because the wxxml module can be checked out and built >separate from the wxjab module. I'd like to keep it that way. > >(At UCSC, we're using the wxxml module to do...well, XML stuff. We don't >need wxjab.) > >This is also why I wasn't thinking we'd have a top-level Makefile. > >What are your thoughts on this? If someone were to check out only the wxxml >module, then they wouldn't get the top-level Makefile anyway. Right? What >about if they only checked out the wxxml and wxjab modules, but not convey? > >Hopefully this gives you an idea of my thinking. I guess I would like a >top-level Makefile as long as it can detect which modules have been checked >out and only build those. Should it also build Convey Java?</andy> > >(5) >I'd prefer not to have to place a top-level convey Makefile in the >repository. >Having a makefile in the top-level directory will allow a recursive build >process which is convienent to automate the entire build. > >That's all for now. Enjoy your weekends. > >Andy > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >convey-developers mailing list >con...@li... >https://lists.sourceforge.net/lists/listinfo/convey-developers _________________________________________________________________ Share your photos without swamping your Inbox. Get Hotmail Extra Storage today! http://join.msn.com/?PAGE=features/es |
|
From: Andy A. <ag...@sb...> - 2003-09-27 23:40:24
|
Scott,
-----Original Message-----
From: con...@li...
[mailto:con...@li...]On Behalf Of Scott
Luan
Sent: Saturday, September 27, 2003 12:56 PM
To: con...@li...
Subject: RE: [convey-developers] convey 0.4?
Hello Andy,
Thanks for the info.
(1) The error generated while making wxjab.o is listed below:
In file included from wxjab.cpp:1:
../../wxjab/include/wxjab.h:112: parse error before `,'
../../wxjab/include/wxjab.h:112: stray '\' in program
../../wxjab/include/wxjab.h:113: stray '\' in program
../../wxjab/include/wxjab.h:114: stray '\' in program
../../wxjab/include/wxjab.h:115: stray '\' in program
This is the macro definition in wxjab.h:
#define EVT_JABBER_MESSAGE(id, func) \
DECLARE_EVENT_TABLE_ENTRY(wxEVT_JABBER_MESSAGE, id, -1, \
(wxObjectEventFunction) \
(wxEventFunction) \
(wxJabberMessageEventFunction) & func, \
(wxObject *) NULL ),<--- ends here.
Note that this macro is not used anywhere.
<andy>Sweet.</andy>
(2) The build error for wxjab, I discovered, is due to a mistaken identity
in the header files. Specifically testapp.h for both wxxml and wxjab.
<andy>Perhaps they should be renamed to testxml and testjab, or
something.</andy>
(3) I am not sure if we decided to include the makefiles in the source tree.
I think it is a good idea so that we can all use the same build process.
But.. there may be incompatibilities with MS' nmake. Hmmm... Well, perhaps
we just have to sync up manually and accept the amusing fact that we are
using 4 platforms among 3 people! :-) Well, if we have decided to include
the makefiles, I don't believe I can create/checkin any files in any
directory other than wxjab. Perhaps for the sake of convienence, the
adminstrative demands may be relaxed for this informal group of fun-loving
developers. :-)
<andy>You can't checkin files? Hmmm. I'll look into it and give you
permissions for the whole source tree.
Makefiles are definately good. This will allow us to synch up Mac OS X,
Linux, Solaris, and the like. I definately think we should have them. I also
would like to have MSVC and Project Builder projects for GUI debugging. Of
course, it is difficult to keep them synched with Makefiles. In practice,
the GUI project builds usually breakdown more frequently. That's okay,
though.
Makefiles with Windows are almost never compatible with 'nixes for many
reasons, so I don't even care to try. That was a plus with Java. You could
better streamline the build systems between OSes. However, in practice, in
didn't always work.</andy>
(4) >can we provide a way to indicate to the wxjab build system where it
can find the wxxml library.
yes, we can use the -L switch for the linker
<andy>What I mean is by using some kind of configure or autoconf mechanism.
The reason is that I'd like wxxml and wxjab to be as separate as possible. I
was thinking this because the wxxml module can be checked out and built
separate from the wxjab module. I'd like to keep it that way.
(At UCSC, we're using the wxxml module to do...well, XML stuff. We don't
need wxjab.)
This is also why I wasn't thinking we'd have a top-level Makefile.
What are your thoughts on this? If someone were to check out only the wxxml
module, then they wouldn't get the top-level Makefile anyway. Right? What
about if they only checked out the wxxml and wxjab modules, but not convey?
Hopefully this gives you an idea of my thinking. I guess I would like a
top-level Makefile as long as it can detect which modules have been checked
out and only build those. Should it also build Convey Java?</andy>
(5) >I'd prefer not to have to place a top-level convey Makefile in the
repository.
Having a makefile in the top-level directory will allow a recursive build
process which is convienent to automate the entire build.
That's all for now. Enjoy your weekends.
Andy
|
|
From: Scott L. <sco...@ho...> - 2003-09-27 23:24:47
|
>(2) The build error for wxjab, I discovered, is due to a mistaken identity
>in the header files. Specifically testapp.h for both wxxml and wxjab.
>
error in my makefile. sorry, i didn't make that clear.
>From: "Scott Luan" <sco...@ho...>
>Reply-To: con...@li...
>To: con...@li...
>Subject: RE: [convey-developers] convey 0.4?
>Date: Sat, 27 Sep 2003 12:56:02 -0700
>
>Hello Andy,
>
>Thanks for the info.
>
>(1) The error generated while making wxjab.o is listed below:
>
>In file included from wxjab.cpp:1:
>../../wxjab/include/wxjab.h:112: parse error before `,'
>../../wxjab/include/wxjab.h:112: stray '\' in program
>../../wxjab/include/wxjab.h:113: stray '\' in program
>../../wxjab/include/wxjab.h:114: stray '\' in program
>../../wxjab/include/wxjab.h:115: stray '\' in program
>
>This is the macro definition in wxjab.h:
>#define EVT_JABBER_MESSAGE(id, func) \
>
> DECLARE_EVENT_TABLE_ENTRY(wxEVT_JABBER_MESSAGE, id, -1, \
>
> (wxObjectEventFunction) \
>
> (wxEventFunction) \
>
> (wxJabberMessageEventFunction) & func, \
>
> (wxObject *) NULL ),<--- ends here.
>
>Note that this macro is not used anywhere.
>
>(2) The build error for wxjab, I discovered, is due to a mistaken identity
>in the header files. Specifically testapp.h for both wxxml and wxjab.
>
>(3) I am not sure if we decided to include the makefiles in the source
>tree. I think it is a good idea so that we can all use the same build
>process. But.. there may be incompatibilities with MS' nmake. Hmmm...
>Well, perhaps we just have to sync up manually and accept the amusing fact
>that we are using 4 platforms among 3 people! :-) Well, if we have
>decided to include the makefiles, I don't believe I can create/checkin any
>files in any directory other than wxjab. Perhaps for the sake of
>convienence, the adminstrative demands may be relaxed for this informal
>group of fun-loving developers. :-)
>
>(4) >can we provide a way to indicate to the wxjab build system where it
>can find the wxxml library.
>yes, we can use the -L switch for the linker
>
>(5) >I'd prefer not to have to place a top-level convey Makefile in the
>repository.
>Having a makefile in the top-level directory will allow a recursive build
>process which is convienent to automate the entire build.
>
>Take care,
>Scott
>
>>From: "Andy Ames" <ag...@sb...>
>>Reply-To: con...@li...
>>To: <con...@li...>
>>Subject: RE: [convey-developers] convey 0.4?
>>Date: Thu, 25 Sep 2003 21:23:17 -0700
>>
>>Scott,
>>
>>I haven't had a chance to look at the errors encountered while building
>>wxjab until now.
>>
>>1) Have you fixed any of them? Are you able to build testapp successfully?
>>
>>2) What was the problem with the EVT_JABBER_MESSAGE macro? Was there a
>>build
>>error?
>>
>>3) I'm also unsure about IMPLEMENT_APP_NO_MAIN. Here's how its defined in
>>my
>>version. I believe it should be the same on all platforms because it's
>>defined in "wx/app.h" as opposed to "wx/msw/app.h" or "wx/gtk/app.h".
>>
>>// Use this macro if you want to define your own main() or WinMain()
>>function
>>// and call wxEntry() from there.
>>#define IMPLEMENT_APP_NO_MAIN(appname) \
>> wxApp *wxCreateApp() \
>> { \
>> wxApp::CheckBuildOptions(wxBuildOptions()); \
>> return new appname; \
>> } \
>> wxAppInitializer wxTheAppInitializer((wxAppInitializerFunction)
>>wxCreateApp); \
>> appname& wxGetApp() { return *(appname *)wxTheApp; }
>>
>>Is this the same in your version?
>>
>>4) Can you make the wxxml Makefile so that it builds a library as does
>>expat. If you want, you can just have the wxxml Makefile build expat and
>>wxxml into a single library. Then, wxjab would link to that one library.
>>That way, it is easy for applications to use only wxxml.
>>
>>Can you also modify wxjab so that a library is generated. For both wxxml
>>and
>>wxjab, the testapp can simply link to the library. Does this make sense?
>>The
>>libraries should be placed
>>
>>That way, the build configuration will more closely resemble that of my
>>MSW
>>projects and Ed's Project Builder projects.
>>
>>The libraries are called wxxml, wxxmld, wxjab, and wxjabd. Of course, you
>>can prepend "lib" to the names while keeping the ".a" extension. I believe
>>we did this on Ed's Mac OS X machine.
>>
>>I had the libraries generated to a lib directory parallel to the include
>>and
>>src directories. I guess, release and debug versions are not really
>>necessary, yet. Also, I had the testapp executables generated to bin, also
>>parallel to lib.
>>
>>One more thing about the Makefiles, can we provide a way to indicate to
>>the
>>wxjab build system where it can find the wxxml library. That way, we don't
>>have to rely on the wxxml and wxjab directories being parallel. I'd prefer
>>not to have to place a top-level convey Makefile in the repository.
>>
>>Blah, blah, blah. I hope you guys are doing well.
>>
>>Andy
>>
>>-----Original Message-----
>>From: con...@li...
>>[mailto:con...@li...]On Behalf Of Scott
>>Luan
>>Sent: Tuesday, September 23, 2003 5:46 PM
>>To: con...@li...
>>Subject: Re: [convey-developers] convey 0.4?
>>
>>
>>Hello Ed, Andy.
>>
>>Thanks for the update Ed. That's useful information! Yes, templates
>>would
>>help speed things up.
>>
>>On other notes:
>>
>>(1) Before the number of source files increases, I suggest that this would
>>be a good time to incorporate a build mechanism in the source tree. I
>>provided sample makefiles below.
>>
>>(2) I encountered a build error when I tried to build the testapp in the
>>wxjab directory. I want to ping you guys before I dig further into
>>wxWindows. The build output is directly below. It seems that this may be
>>a
>>wxGTK-2.4.1 problem and probably you are not using the gtk version.
>>Specifically, the problem *seems* to be the macro IMPLEMENT_APP_NO_MAIN in
>>wx/app.h since line7 of testapp.cpp is "IMPLEMENT_APP(wxTestApp)". Also,
>>I
>>made a minor modification to wxjab.h to build wxjab.o (comment out the
>>EVT_JABBER_MESSAGE macro). Andy - just to verify that the problem is not
>>in
>>convey. Well, any suggestion is appreciated.
>>
>>make[1]: Entering directory `/home/sluan/src/convey/wxjab/src'
>>g++ -g -Wall -Wno-unused -Wno-sign-compare -I../../wxxml/include
>>-I../../wxxml/expat/include -I../../wxjab/include -L../../wxxml/expat/src
>>`wx-config --cxxflags --libs` testapp.cpp -o testapp wxjab.o -lexpat
>>testapp.cpp: In function `class wxApp * wxCreateApp()':
>>testapp.cpp:7: parse error before `;'
>>testapp.cpp:7: warning: control reaches end of non-void function
>>`wxCreateApp()'
>>testapp.cpp: At top level:
>>testapp.cpp:7: syntax error before `&'
>>testapp.cpp:9: syntax error before `::'
>>testapp.cpp:16: `pTextDlg' was not declared in this scope
>>testapp.cpp:17: syntax error before `->'
>>testapp.cpp:19: ANSI C++ forbids declaration `pTextDlg' with no type
>>testapp.cpp:19: initialization to `int' from `wxTextEntryDialog *' lacks a
>>cast
>>testapp.cpp:20: parse error before `if'
>>
>>...
>>..
>>.
>>
>>
>>Thanks,
>>Scott
>>
>>
>>
>>#-----------------------------------------------
>># makefile for convey toplevel directory
>>#-----------------------------------------------
>>
>>all:
>> cd wxxml/expat/src ; make all
>> cd wxxml/src ; make all
>> cd wxjab/src ; make all
>>
>>clean:
>> cd wxxml/expat/src ; make clean
>> cd wxxml/src ; make clean
>> cd wxjab/src ; make clean
>>
>>#-----------------------------------------------
>># makefile for convey/wxxml/expat/src directory
>>#-----------------------------------------------
>>
>>.PHONY: clean
>>
>>CC= gcc
>>
>>CFLAGS = -g -Wall -Wno-unused -Wno-sign-compare -I../include
>>
>>SRCS = xmlparse.c xmlrole.c xmltok.c
>>OBJS = xmlparse.o xmlrole.o xmltok.o
>>
>>default: $(OBJS)
>>all: $(OBJS) libexpat
>>
>>%.o: %.c
>> $(CC) $(CFLAGS) -c -o $@ $*.c
>>
>>libexpat: $(OBJS)
>> ar r libexpat.a $(OBJS)
>>
>>clean:
>> rm -f $(OBJS) libexpat.a
>>
>>#-----------------------------------------------
>># makefile for convey/wxxml/src directory
>>#-----------------------------------------------
>>
>>.PHONY: clean
>>
>>CC= g++
>>
>>CFLAGS = -g -Wall -Wno-unused -Wno-sign-compare -I../../wxxml/include
>>-I../../wxxml/expat/include -L../../wxxml/expat/src
>>
>>SRCS = xml.cpp xmlin.cpp xmlout.cpp
>>OBJS = xml.o xmlin.o xmlout.o
>>
>>default: $(OBJS)
>>all: $(OBJS) testapp
>>
>>%.o: %.cpp
>> $(CC) $(CFLAGS) `wx-config --cxxflags` -c $*.cpp -o $@
>>
>>testapp: testapp.cpp $(OBJS)
>> $(CC) $(CFLAGS) `wx-config --cxxflags --libs` testapp.cpp -o $@ $(OBJS)
>>-lexpat
>> chmod a+x testapp
>>
>>clean:
>> rm -f $(OBJS) testapp
>>
>># ----------------------------------------------
>># makefile for convey/wxjab/src directory
>>#-----------------------------------------------
>>
>>.PHONY: clean
>>
>>CC= g++
>>
>>CFLAGS = -g -Wall -Wno-unused -Wno-sign-compare -I../../wxxml/include
>>-I../../wxxml/expat/include -I../../wxjab/include -L../../wxxml/expat/src
>>
>>SRCS = wxjab.cpp
>>OBJS = wxjab.o
>>
>>default: $(OBJS)
>>all: $(OBJS) testapp
>>
>>%.o: %.cpp
>> $(CC) $(CFLAGS) `wx-config --cxxflags` -c $*.cpp -o $@
>>
>>testapp: testapp.cpp
>> $(CC) $(CFLAGS) `wx-config --cxxflags --libs` testapp.cpp -o $@ $(OBJS)
>>-lexpat
>> chmod a+x testapp
>>
>>clean:
>> rm -f $(OBJS) testapp
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>convey-developers mailing list
>>con...@li...
>>https://lists.sourceforge.net/lists/listinfo/convey-developers
>
>_________________________________________________________________
>Add MSN 8 Internet Software to your existing Internet access and enjoy
>patented spam protection and more. Sign up now!
>http://join.msn.com/?page=dept/byoa
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>convey-developers mailing list
>con...@li...
>https://lists.sourceforge.net/lists/listinfo/convey-developers
_________________________________________________________________
Help protect your PC. Get a FREE computer virus scan online from McAfee.
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
|
|
From: Scott L. <sco...@ho...> - 2003-09-27 19:57:26
|
Hello Andy,
Thanks for the info.
(1) The error generated while making wxjab.o is listed below:
In file included from wxjab.cpp:1:
../../wxjab/include/wxjab.h:112: parse error before `,'
../../wxjab/include/wxjab.h:112: stray '\' in program
../../wxjab/include/wxjab.h:113: stray '\' in program
../../wxjab/include/wxjab.h:114: stray '\' in program
../../wxjab/include/wxjab.h:115: stray '\' in program
This is the macro definition in wxjab.h:
#define EVT_JABBER_MESSAGE(id, func) \
DECLARE_EVENT_TABLE_ENTRY(wxEVT_JABBER_MESSAGE, id, -1, \
(wxObjectEventFunction) \
(wxEventFunction) \
(wxJabberMessageEventFunction) & func, \
(wxObject *) NULL ),<--- ends here.
Note that this macro is not used anywhere.
(2) The build error for wxjab, I discovered, is due to a mistaken identity
in the header files. Specifically testapp.h for both wxxml and wxjab.
(3) I am not sure if we decided to include the makefiles in the source tree.
I think it is a good idea so that we can all use the same build process.
But.. there may be incompatibilities with MS' nmake. Hmmm... Well, perhaps
we just have to sync up manually and accept the amusing fact that we are
using 4 platforms among 3 people! :-) Well, if we have decided to include
the makefiles, I don't believe I can create/checkin any files in any
directory other than wxjab. Perhaps for the sake of convienence, the
adminstrative demands may be relaxed for this informal group of fun-loving
developers. :-)
(4) >can we provide a way to indicate to the wxjab build system where it
can find the wxxml library.
yes, we can use the -L switch for the linker
(5) >I'd prefer not to have to place a top-level convey Makefile in the
repository.
Having a makefile in the top-level directory will allow a recursive build
process which is convienent to automate the entire build.
Take care,
Scott
>From: "Andy Ames" <ag...@sb...>
>Reply-To: con...@li...
>To: <con...@li...>
>Subject: RE: [convey-developers] convey 0.4?
>Date: Thu, 25 Sep 2003 21:23:17 -0700
>
>Scott,
>
>I haven't had a chance to look at the errors encountered while building
>wxjab until now.
>
>1) Have you fixed any of them? Are you able to build testapp successfully?
>
>2) What was the problem with the EVT_JABBER_MESSAGE macro? Was there a
>build
>error?
>
>3) I'm also unsure about IMPLEMENT_APP_NO_MAIN. Here's how its defined in
>my
>version. I believe it should be the same on all platforms because it's
>defined in "wx/app.h" as opposed to "wx/msw/app.h" or "wx/gtk/app.h".
>
>// Use this macro if you want to define your own main() or WinMain()
>function
>// and call wxEntry() from there.
>#define IMPLEMENT_APP_NO_MAIN(appname) \
> wxApp *wxCreateApp() \
> { \
> wxApp::CheckBuildOptions(wxBuildOptions()); \
> return new appname; \
> } \
> wxAppInitializer wxTheAppInitializer((wxAppInitializerFunction)
>wxCreateApp); \
> appname& wxGetApp() { return *(appname *)wxTheApp; }
>
>Is this the same in your version?
>
>4) Can you make the wxxml Makefile so that it builds a library as does
>expat. If you want, you can just have the wxxml Makefile build expat and
>wxxml into a single library. Then, wxjab would link to that one library.
>That way, it is easy for applications to use only wxxml.
>
>Can you also modify wxjab so that a library is generated. For both wxxml
>and
>wxjab, the testapp can simply link to the library. Does this make sense?
>The
>libraries should be placed
>
>That way, the build configuration will more closely resemble that of my MSW
>projects and Ed's Project Builder projects.
>
>The libraries are called wxxml, wxxmld, wxjab, and wxjabd. Of course, you
>can prepend "lib" to the names while keeping the ".a" extension. I believe
>we did this on Ed's Mac OS X machine.
>
>I had the libraries generated to a lib directory parallel to the include
>and
>src directories. I guess, release and debug versions are not really
>necessary, yet. Also, I had the testapp executables generated to bin, also
>parallel to lib.
>
>One more thing about the Makefiles, can we provide a way to indicate to the
>wxjab build system where it can find the wxxml library. That way, we don't
>have to rely on the wxxml and wxjab directories being parallel. I'd prefer
>not to have to place a top-level convey Makefile in the repository.
>
>Blah, blah, blah. I hope you guys are doing well.
>
>Andy
>
>-----Original Message-----
>From: con...@li...
>[mailto:con...@li...]On Behalf Of Scott
>Luan
>Sent: Tuesday, September 23, 2003 5:46 PM
>To: con...@li...
>Subject: Re: [convey-developers] convey 0.4?
>
>
>Hello Ed, Andy.
>
>Thanks for the update Ed. That's useful information! Yes, templates
>would
>help speed things up.
>
>On other notes:
>
>(1) Before the number of source files increases, I suggest that this would
>be a good time to incorporate a build mechanism in the source tree. I
>provided sample makefiles below.
>
>(2) I encountered a build error when I tried to build the testapp in the
>wxjab directory. I want to ping you guys before I dig further into
>wxWindows. The build output is directly below. It seems that this may be
>a
>wxGTK-2.4.1 problem and probably you are not using the gtk version.
>Specifically, the problem *seems* to be the macro IMPLEMENT_APP_NO_MAIN in
>wx/app.h since line7 of testapp.cpp is "IMPLEMENT_APP(wxTestApp)". Also, I
>made a minor modification to wxjab.h to build wxjab.o (comment out the
>EVT_JABBER_MESSAGE macro). Andy - just to verify that the problem is not
>in
>convey. Well, any suggestion is appreciated.
>
>make[1]: Entering directory `/home/sluan/src/convey/wxjab/src'
>g++ -g -Wall -Wno-unused -Wno-sign-compare -I../../wxxml/include
>-I../../wxxml/expat/include -I../../wxjab/include -L../../wxxml/expat/src
>`wx-config --cxxflags --libs` testapp.cpp -o testapp wxjab.o -lexpat
>testapp.cpp: In function `class wxApp * wxCreateApp()':
>testapp.cpp:7: parse error before `;'
>testapp.cpp:7: warning: control reaches end of non-void function
>`wxCreateApp()'
>testapp.cpp: At top level:
>testapp.cpp:7: syntax error before `&'
>testapp.cpp:9: syntax error before `::'
>testapp.cpp:16: `pTextDlg' was not declared in this scope
>testapp.cpp:17: syntax error before `->'
>testapp.cpp:19: ANSI C++ forbids declaration `pTextDlg' with no type
>testapp.cpp:19: initialization to `int' from `wxTextEntryDialog *' lacks a
>cast
>testapp.cpp:20: parse error before `if'
>
>...
>..
>.
>
>
>Thanks,
>Scott
>
>
>
>#-----------------------------------------------
># makefile for convey toplevel directory
>#-----------------------------------------------
>
>all:
> cd wxxml/expat/src ; make all
> cd wxxml/src ; make all
> cd wxjab/src ; make all
>
>clean:
> cd wxxml/expat/src ; make clean
> cd wxxml/src ; make clean
> cd wxjab/src ; make clean
>
>#-----------------------------------------------
># makefile for convey/wxxml/expat/src directory
>#-----------------------------------------------
>
>.PHONY: clean
>
>CC= gcc
>
>CFLAGS = -g -Wall -Wno-unused -Wno-sign-compare -I../include
>
>SRCS = xmlparse.c xmlrole.c xmltok.c
>OBJS = xmlparse.o xmlrole.o xmltok.o
>
>default: $(OBJS)
>all: $(OBJS) libexpat
>
>%.o: %.c
> $(CC) $(CFLAGS) -c -o $@ $*.c
>
>libexpat: $(OBJS)
> ar r libexpat.a $(OBJS)
>
>clean:
> rm -f $(OBJS) libexpat.a
>
>#-----------------------------------------------
># makefile for convey/wxxml/src directory
>#-----------------------------------------------
>
>.PHONY: clean
>
>CC= g++
>
>CFLAGS = -g -Wall -Wno-unused -Wno-sign-compare -I../../wxxml/include
>-I../../wxxml/expat/include -L../../wxxml/expat/src
>
>SRCS = xml.cpp xmlin.cpp xmlout.cpp
>OBJS = xml.o xmlin.o xmlout.o
>
>default: $(OBJS)
>all: $(OBJS) testapp
>
>%.o: %.cpp
> $(CC) $(CFLAGS) `wx-config --cxxflags` -c $*.cpp -o $@
>
>testapp: testapp.cpp $(OBJS)
> $(CC) $(CFLAGS) `wx-config --cxxflags --libs` testapp.cpp -o $@ $(OBJS)
>-lexpat
> chmod a+x testapp
>
>clean:
> rm -f $(OBJS) testapp
>
># ----------------------------------------------
># makefile for convey/wxjab/src directory
>#-----------------------------------------------
>
>.PHONY: clean
>
>CC= g++
>
>CFLAGS = -g -Wall -Wno-unused -Wno-sign-compare -I../../wxxml/include
>-I../../wxxml/expat/include -I../../wxjab/include -L../../wxxml/expat/src
>
>SRCS = wxjab.cpp
>OBJS = wxjab.o
>
>default: $(OBJS)
>all: $(OBJS) testapp
>
>%.o: %.cpp
> $(CC) $(CFLAGS) `wx-config --cxxflags` -c $*.cpp -o $@
>
>testapp: testapp.cpp
> $(CC) $(CFLAGS) `wx-config --cxxflags --libs` testapp.cpp -o $@ $(OBJS)
>-lexpat
> chmod a+x testapp
>
>clean:
> rm -f $(OBJS) testapp
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>convey-developers mailing list
>con...@li...
>https://lists.sourceforge.net/lists/listinfo/convey-developers
_________________________________________________________________
Add MSN 8 Internet Software to your existing Internet access and enjoy
patented spam protection and more. Sign up now!
http://join.msn.com/?page=dept/byoa
|
|
From: Andy A. <ag...@sb...> - 2003-09-26 04:23:21
|
Scott,
I haven't had a chance to look at the errors encountered while building
wxjab until now.
1) Have you fixed any of them? Are you able to build testapp successfully?
2) What was the problem with the EVT_JABBER_MESSAGE macro? Was there a build
error?
3) I'm also unsure about IMPLEMENT_APP_NO_MAIN. Here's how its defined in my
version. I believe it should be the same on all platforms because it's
defined in "wx/app.h" as opposed to "wx/msw/app.h" or "wx/gtk/app.h".
// Use this macro if you want to define your own main() or WinMain()
function
// and call wxEntry() from there.
#define IMPLEMENT_APP_NO_MAIN(appname) \
wxApp *wxCreateApp() \
{ \
wxApp::CheckBuildOptions(wxBuildOptions()); \
return new appname; \
} \
wxAppInitializer wxTheAppInitializer((wxAppInitializerFunction)
wxCreateApp); \
appname& wxGetApp() { return *(appname *)wxTheApp; }
Is this the same in your version?
4) Can you make the wxxml Makefile so that it builds a library as does
expat. If you want, you can just have the wxxml Makefile build expat and
wxxml into a single library. Then, wxjab would link to that one library.
That way, it is easy for applications to use only wxxml.
Can you also modify wxjab so that a library is generated. For both wxxml and
wxjab, the testapp can simply link to the library. Does this make sense? The
libraries should be placed
That way, the build configuration will more closely resemble that of my MSW
projects and Ed's Project Builder projects.
The libraries are called wxxml, wxxmld, wxjab, and wxjabd. Of course, you
can prepend "lib" to the names while keeping the ".a" extension. I believe
we did this on Ed's Mac OS X machine.
I had the libraries generated to a lib directory parallel to the include and
src directories. I guess, release and debug versions are not really
necessary, yet. Also, I had the testapp executables generated to bin, also
parallel to lib.
One more thing about the Makefiles, can we provide a way to indicate to the
wxjab build system where it can find the wxxml library. That way, we don't
have to rely on the wxxml and wxjab directories being parallel. I'd prefer
not to have to place a top-level convey Makefile in the repository.
Blah, blah, blah. I hope you guys are doing well.
Andy
-----Original Message-----
From: con...@li...
[mailto:con...@li...]On Behalf Of Scott
Luan
Sent: Tuesday, September 23, 2003 5:46 PM
To: con...@li...
Subject: Re: [convey-developers] convey 0.4?
Hello Ed, Andy.
Thanks for the update Ed. That's useful information! Yes, templates would
help speed things up.
On other notes:
(1) Before the number of source files increases, I suggest that this would
be a good time to incorporate a build mechanism in the source tree. I
provided sample makefiles below.
(2) I encountered a build error when I tried to build the testapp in the
wxjab directory. I want to ping you guys before I dig further into
wxWindows. The build output is directly below. It seems that this may be a
wxGTK-2.4.1 problem and probably you are not using the gtk version.
Specifically, the problem *seems* to be the macro IMPLEMENT_APP_NO_MAIN in
wx/app.h since line7 of testapp.cpp is "IMPLEMENT_APP(wxTestApp)". Also, I
made a minor modification to wxjab.h to build wxjab.o (comment out the
EVT_JABBER_MESSAGE macro). Andy - just to verify that the problem is not in
convey. Well, any suggestion is appreciated.
make[1]: Entering directory `/home/sluan/src/convey/wxjab/src'
g++ -g -Wall -Wno-unused -Wno-sign-compare -I../../wxxml/include
-I../../wxxml/expat/include -I../../wxjab/include -L../../wxxml/expat/src
`wx-config --cxxflags --libs` testapp.cpp -o testapp wxjab.o -lexpat
testapp.cpp: In function `class wxApp * wxCreateApp()':
testapp.cpp:7: parse error before `;'
testapp.cpp:7: warning: control reaches end of non-void function
`wxCreateApp()'
testapp.cpp: At top level:
testapp.cpp:7: syntax error before `&'
testapp.cpp:9: syntax error before `::'
testapp.cpp:16: `pTextDlg' was not declared in this scope
testapp.cpp:17: syntax error before `->'
testapp.cpp:19: ANSI C++ forbids declaration `pTextDlg' with no type
testapp.cpp:19: initialization to `int' from `wxTextEntryDialog *' lacks a
cast
testapp.cpp:20: parse error before `if'
...
..
.
Thanks,
Scott
#-----------------------------------------------
# makefile for convey toplevel directory
#-----------------------------------------------
all:
cd wxxml/expat/src ; make all
cd wxxml/src ; make all
cd wxjab/src ; make all
clean:
cd wxxml/expat/src ; make clean
cd wxxml/src ; make clean
cd wxjab/src ; make clean
#-----------------------------------------------
# makefile for convey/wxxml/expat/src directory
#-----------------------------------------------
.PHONY: clean
CC= gcc
CFLAGS = -g -Wall -Wno-unused -Wno-sign-compare -I../include
SRCS = xmlparse.c xmlrole.c xmltok.c
OBJS = xmlparse.o xmlrole.o xmltok.o
default: $(OBJS)
all: $(OBJS) libexpat
%.o: %.c
$(CC) $(CFLAGS) -c -o $@ $*.c
libexpat: $(OBJS)
ar r libexpat.a $(OBJS)
clean:
rm -f $(OBJS) libexpat.a
#-----------------------------------------------
# makefile for convey/wxxml/src directory
#-----------------------------------------------
.PHONY: clean
CC= g++
CFLAGS = -g -Wall -Wno-unused -Wno-sign-compare -I../../wxxml/include
-I../../wxxml/expat/include -L../../wxxml/expat/src
SRCS = xml.cpp xmlin.cpp xmlout.cpp
OBJS = xml.o xmlin.o xmlout.o
default: $(OBJS)
all: $(OBJS) testapp
%.o: %.cpp
$(CC) $(CFLAGS) `wx-config --cxxflags` -c $*.cpp -o $@
testapp: testapp.cpp $(OBJS)
$(CC) $(CFLAGS) `wx-config --cxxflags --libs` testapp.cpp -o $@ $(OBJS)
-lexpat
chmod a+x testapp
clean:
rm -f $(OBJS) testapp
# ----------------------------------------------
# makefile for convey/wxjab/src directory
#-----------------------------------------------
.PHONY: clean
CC= g++
CFLAGS = -g -Wall -Wno-unused -Wno-sign-compare -I../../wxxml/include
-I../../wxxml/expat/include -I../../wxjab/include -L../../wxxml/expat/src
SRCS = wxjab.cpp
OBJS = wxjab.o
default: $(OBJS)
all: $(OBJS) testapp
%.o: %.cpp
$(CC) $(CFLAGS) `wx-config --cxxflags` -c $*.cpp -o $@
testapp: testapp.cpp
$(CC) $(CFLAGS) `wx-config --cxxflags --libs` testapp.cpp -o $@ $(OBJS)
-lexpat
chmod a+x testapp
clean:
rm -f $(OBJS) testapp
|
|
From: Scott L. <sco...@ho...> - 2003-09-24 00:46:58
|
Hello Ed, Andy. Thanks for the update Ed. That's useful information! Yes, templates would help speed things up. On other notes: (1) Before the number of source files increases, I suggest that this would be a good time to incorporate a build mechanism in the source tree. I provided sample makefiles below. (2) I encountered a build error when I tried to build the testapp in the wxjab directory. I want to ping you guys before I dig further into wxWindows. The build output is directly below. It seems that this may be a wxGTK-2.4.1 problem and probably you are not using the gtk version. Specifically, the problem *seems* to be the macro IMPLEMENT_APP_NO_MAIN in wx/app.h since line7 of testapp.cpp is "IMPLEMENT_APP(wxTestApp)". Also, I made a minor modification to wxjab.h to build wxjab.o (comment out the EVT_JABBER_MESSAGE macro). Andy - just to verify that the problem is not in convey. Well, any suggestion is appreciated. make[1]: Entering directory `/home/sluan/src/convey/wxjab/src' g++ -g -Wall -Wno-unused -Wno-sign-compare -I../../wxxml/include -I../../wxxml/expat/include -I../../wxjab/include -L../../wxxml/expat/src `wx-config --cxxflags --libs` testapp.cpp -o testapp wxjab.o -lexpat testapp.cpp: In function `class wxApp * wxCreateApp()': testapp.cpp:7: parse error before `;' testapp.cpp:7: warning: control reaches end of non-void function `wxCreateApp()' testapp.cpp: At top level: testapp.cpp:7: syntax error before `&' testapp.cpp:9: syntax error before `::' testapp.cpp:16: `pTextDlg' was not declared in this scope testapp.cpp:17: syntax error before `->' testapp.cpp:19: ANSI C++ forbids declaration `pTextDlg' with no type testapp.cpp:19: initialization to `int' from `wxTextEntryDialog *' lacks a cast testapp.cpp:20: parse error before `if' ... .. . Thanks, Scott #----------------------------------------------- # makefile for convey toplevel directory #----------------------------------------------- all: cd wxxml/expat/src ; make all cd wxxml/src ; make all cd wxjab/src ; make all clean: cd wxxml/expat/src ; make clean cd wxxml/src ; make clean cd wxjab/src ; make clean #----------------------------------------------- # makefile for convey/wxxml/expat/src directory #----------------------------------------------- .PHONY: clean CC= gcc CFLAGS = -g -Wall -Wno-unused -Wno-sign-compare -I../include SRCS = xmlparse.c xmlrole.c xmltok.c OBJS = xmlparse.o xmlrole.o xmltok.o default: $(OBJS) all: $(OBJS) libexpat %.o: %.c $(CC) $(CFLAGS) -c -o $@ $*.c libexpat: $(OBJS) ar r libexpat.a $(OBJS) clean: rm -f $(OBJS) libexpat.a #----------------------------------------------- # makefile for convey/wxxml/src directory #----------------------------------------------- .PHONY: clean CC= g++ CFLAGS = -g -Wall -Wno-unused -Wno-sign-compare -I../../wxxml/include -I../../wxxml/expat/include -L../../wxxml/expat/src SRCS = xml.cpp xmlin.cpp xmlout.cpp OBJS = xml.o xmlin.o xmlout.o default: $(OBJS) all: $(OBJS) testapp %.o: %.cpp $(CC) $(CFLAGS) `wx-config --cxxflags` -c $*.cpp -o $@ testapp: testapp.cpp $(OBJS) $(CC) $(CFLAGS) `wx-config --cxxflags --libs` testapp.cpp -o $@ $(OBJS) -lexpat chmod a+x testapp clean: rm -f $(OBJS) testapp # ---------------------------------------------- # makefile for convey/wxjab/src directory #----------------------------------------------- .PHONY: clean CC= g++ CFLAGS = -g -Wall -Wno-unused -Wno-sign-compare -I../../wxxml/include -I../../wxxml/expat/include -I../../wxjab/include -L../../wxxml/expat/src SRCS = wxjab.cpp OBJS = wxjab.o default: $(OBJS) all: $(OBJS) testapp %.o: %.cpp $(CC) $(CFLAGS) `wx-config --cxxflags` -c $*.cpp -o $@ testapp: testapp.cpp $(CC) $(CFLAGS) `wx-config --cxxflags --libs` testapp.cpp -o $@ $(OBJS) -lexpat chmod a+x testapp clean: rm -f $(OBJS) testapp >From: eD Braunhut <edb...@ca...> >Reply-To: con...@li... >To: con...@li... >Subject: Re: [convey-developers] convey 0.4? >Date: Mon, 22 Sep 2003 18:22:39 -0700 > >Welcome back Scott. It must be the American food... > >Well, I haven't used Convey much in my class because I haven't told my >students much about it yet. I've been experimenting with it and it is a bit >difficult to create stuff on the fly. It seems communication visually would >be slow from a user point of view. Funny, I've been worried about network >speed for so long I never thought about user speed. However, I talked with >Andy today about templates and I think if it was possible to create them, >it may actually be alot faster to communicate this way. > >The other thing is that I have been crazily creating curriculum for this >math tutoring class I got passed the curriculum committe last semester. It >feels like I'm writing a book about math tutoring. So it's been a full dish >with that and the fact we are down several excellent tutors. I've been >spending about 6 of my 8 hours per day out on the floor tutoring (as >opposed to 1 or 2). > >Ed > >Scott Luan wrote: > >>Hi Andy, Ed, >> >>Strange. I also got sick when I returned from Japan. I've only recovered >>recently. >> >>Well, hope you all had a great summer and are ready for a new >>semester/season/married-life. >> >>Ed - I'm also interested to find out about your experiences in using >>Convey in class. >> >>Scott >> >>>From: "Andy Ames" <ag...@sb...> >>>Reply-To: con...@li... >>>To: <con...@li...> >>>Subject: RE: [convey-developers] convey 0.4? >>>Date: Sat, 13 Sep 2003 14:49:13 -0700 >>> >>>Hi, Ed and Scott, >>> >>>I returned from Thailand only to get sick the day I got off the plane. At >>>least I wasn't sick while I was there. >>> >>>Ed, out of the bugs you've submitted regarding Convey Java, can you go >>>set >>>there priority values to reflect their importance. Give anything that has >>>been an showstopper a 9 priority. Bugs that have been somewhat of an >>>annoyance, give them an 8. >>> >>>Over the next week, I'll have some time to get to a handful of them. >>> >>>Anyway, has your class been using Convey? I realize it's only a week or >>>two >>>into the semester. But, have you had a chance to use it for real? >>> >>>Andy >>> >>>-----Original Message----- >>>From: con...@li... >>>[mailto:con...@li...]On Behalf Of Andy >>>Ames >>>Sent: Monday, August 25, 2003 6:52 PM >>>To: con...@li... >>>Subject: RE: [convey-developers] convey 0.4? >>> >>> >>>Ed, Scott, >>> >>>I'm married and off to Thailand tomorrow! We're packing now. We'll be >>>back >>>in two weeks on 9/10. >>> >>>Real quick, I like the ideas you presented in your last email, Scott. >>>Specifically, the broadcasting p-2-p chatroom. >>> >>>I won't have time to comment further before leaving. I would certainly >>>like >>>to meet with you two when I return. >>> >>>Enjoy the rest of your summers. >>> >>>Andy >>> >>>-----Original Message----- >>>From: con...@li... >>>[mailto:con...@li...]On Behalf Of Scott >>>Luan >>>Sent: Saturday, August 23, 2003 10:12 PM >>>To: con...@li... >>>Subject: [convey-developers] convey 0.4? >>> >>> >>>Hi Ed, Andy, >>> >>>Thanks for the update Ed. >>> >>>I have tried out the latest Convey. It looks great! Good work guys! >>> >>>I especially enjoyed the tabbed canvases, the pen mode operations of >>>yield/revoke/request, and the auto-send toggle. The layout of the >>>features >>>and buttons is convienent. >>> >>>Well, as for me, I have **finally** finished my cOmPiLeR! It generates >>>unoptimized assembly code for the x86 and SPARC and supports basic OO >>>features. Whew... that took a good part of the summer. Now for what's >>>left >>>of it, I'll be leaving for Japan on Monday and returning mid-September. >>> >>>Have a great few(?) weeks before school starts! :-) >>> >>>Take care, >>>Scott >>> >>>_________________________________________________________________ >>>MSN 8: Get 6 months for $9.95/month. >>>http://join.msn.com/?page=dept/dialup >>> >>> >>> >>>------------------------------------------------------- >>>This SF.net email is sponsored by: VM Ware >>>With VMware you can run multiple operating systems on a single machine. >>>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines >>>at the same time. Free trial click >>>here:http://www.vmware.com/wl/offer/358/0 >>>_______________________________________________ >>>convey-developers mailing list >>>con...@li... >>>https://lists.sourceforge.net/lists/listinfo/convey-developers >>> >>> >>> >>>------------------------------------------------------- >>>This SF.net email is sponsored by: VM Ware >>>With VMware you can run multiple operating systems on a single machine. >>>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines >>>at the same time. Free trial click >>>here:http://www.vmware.com/wl/offer/358/0 >>>_______________________________________________ >>>convey-developers mailing list >>>con...@li... >>>https://lists.sourceforge.net/lists/listinfo/convey-developers >>> >>> >>> >>>------------------------------------------------------- >>>This sf.net email is sponsored by:ThinkGeek >>>Welcome to geek heaven. >>>http://thinkgeek.com/sf >>>_______________________________________________ >>>convey-developers mailing list >>>con...@li... >>>https://lists.sourceforge.net/lists/listinfo/convey-developers >> >> >>_________________________________________________________________ >>Instant message in style with MSN Messenger 6.0. Download it now FREE! >>http://msnmessenger-download.com >> >> >> >>------------------------------------------------------- >>This sf.net email is sponsored by:ThinkGeek >>Welcome to geek heaven. >>http://thinkgeek.com/sf >>_______________________________________________ >>convey-developers mailing list >>con...@li... >>https://lists.sourceforge.net/lists/listinfo/convey-developers > > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >convey-developers mailing list >con...@li... >https://lists.sourceforge.net/lists/listinfo/convey-developers _________________________________________________________________ Get MSN 8 Dial-up Internet Service FREE for one month. Limited time offer-- sign up now! http://join.msn.com/?page=dept/dialup |
|
From: eD B. <edb...@ca...> - 2003-09-23 01:22:28
|
Welcome back Scott. It must be the American food... Well, I haven't used Convey much in my class because I haven't told my students much about it yet. I've been experimenting with it and it is a bit difficult to create stuff on the fly. It seems communication visually would be slow from a user point of view. Funny, I've been worried about network speed for so long I never thought about user speed. However, I talked with Andy today about templates and I think if it was possible to create them, it may actually be alot faster to communicate this way. The other thing is that I have been crazily creating curriculum for this math tutoring class I got passed the curriculum committe last semester. It feels like I'm writing a book about math tutoring. So it's been a full dish with that and the fact we are down several excellent tutors. I've been spending about 6 of my 8 hours per day out on the floor tutoring (as opposed to 1 or 2). Ed Scott Luan wrote: > Hi Andy, Ed, > > Strange. I also got sick when I returned from Japan. I've only > recovered recently. > > Well, hope you all had a great summer and are ready for a new > semester/season/married-life. > > Ed - I'm also interested to find out about your experiences in using > Convey in class. > > Scott > >> From: "Andy Ames" <ag...@sb...> >> Reply-To: con...@li... >> To: <con...@li...> >> Subject: RE: [convey-developers] convey 0.4? >> Date: Sat, 13 Sep 2003 14:49:13 -0700 >> >> Hi, Ed and Scott, >> >> I returned from Thailand only to get sick the day I got off the >> plane. At >> least I wasn't sick while I was there. >> >> Ed, out of the bugs you've submitted regarding Convey Java, can you >> go set >> there priority values to reflect their importance. Give anything that >> has >> been an showstopper a 9 priority. Bugs that have been somewhat of an >> annoyance, give them an 8. >> >> Over the next week, I'll have some time to get to a handful of them. >> >> Anyway, has your class been using Convey? I realize it's only a week >> or two >> into the semester. But, have you had a chance to use it for real? >> >> Andy >> >> -----Original Message----- >> From: con...@li... >> [mailto:con...@li...]On Behalf Of Andy >> Ames >> Sent: Monday, August 25, 2003 6:52 PM >> To: con...@li... >> Subject: RE: [convey-developers] convey 0.4? >> >> >> Ed, Scott, >> >> I'm married and off to Thailand tomorrow! We're packing now. We'll be >> back >> in two weeks on 9/10. >> >> Real quick, I like the ideas you presented in your last email, Scott. >> Specifically, the broadcasting p-2-p chatroom. >> >> I won't have time to comment further before leaving. I would >> certainly like >> to meet with you two when I return. >> >> Enjoy the rest of your summers. >> >> Andy >> >> -----Original Message----- >> From: con...@li... >> [mailto:con...@li...]On Behalf Of Scott >> Luan >> Sent: Saturday, August 23, 2003 10:12 PM >> To: con...@li... >> Subject: [convey-developers] convey 0.4? >> >> >> Hi Ed, Andy, >> >> Thanks for the update Ed. >> >> I have tried out the latest Convey. It looks great! Good work guys! >> >> I especially enjoyed the tabbed canvases, the pen mode operations of >> yield/revoke/request, and the auto-send toggle. The layout of the >> features >> and buttons is convienent. >> >> Well, as for me, I have **finally** finished my cOmPiLeR! It generates >> unoptimized assembly code for the x86 and SPARC and supports basic OO >> features. Whew... that took a good part of the summer. Now for >> what's left >> of it, I'll be leaving for Japan on Monday and returning mid-September. >> >> Have a great few(?) weeks before school starts! :-) >> >> Take care, >> Scott >> >> _________________________________________________________________ >> MSN 8: Get 6 months for $9.95/month. >> http://join.msn.com/?page=dept/dialup >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: VM Ware >> With VMware you can run multiple operating systems on a single machine. >> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines >> at the same time. Free trial click >> here:http://www.vmware.com/wl/offer/358/0 >> _______________________________________________ >> convey-developers mailing list >> con...@li... >> https://lists.sourceforge.net/lists/listinfo/convey-developers >> >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: VM Ware >> With VMware you can run multiple operating systems on a single machine. >> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines >> at the same time. Free trial click >> here:http://www.vmware.com/wl/offer/358/0 >> _______________________________________________ >> convey-developers mailing list >> con...@li... >> https://lists.sourceforge.net/lists/listinfo/convey-developers >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by:ThinkGeek >> Welcome to geek heaven. >> http://thinkgeek.com/sf >> _______________________________________________ >> convey-developers mailing list >> con...@li... >> https://lists.sourceforge.net/lists/listinfo/convey-developers > > > _________________________________________________________________ > Instant message in style with MSN Messenger 6.0. Download it now > FREE! http://msnmessenger-download.com > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > convey-developers mailing list > con...@li... > https://lists.sourceforge.net/lists/listinfo/convey-developers |
|
From: Scott L. <sco...@ho...> - 2003-09-23 01:00:24
|
Hi Andy, Ed, Strange. I also got sick when I returned from Japan. I've only recovered recently. Well, hope you all had a great summer and are ready for a new semester/season/married-life. Ed - I'm also interested to find out about your experiences in using Convey in class. Scott >From: "Andy Ames" <ag...@sb...> >Reply-To: con...@li... >To: <con...@li...> >Subject: RE: [convey-developers] convey 0.4? >Date: Sat, 13 Sep 2003 14:49:13 -0700 > >Hi, Ed and Scott, > >I returned from Thailand only to get sick the day I got off the plane. At >least I wasn't sick while I was there. > >Ed, out of the bugs you've submitted regarding Convey Java, can you go set >there priority values to reflect their importance. Give anything that has >been an showstopper a 9 priority. Bugs that have been somewhat of an >annoyance, give them an 8. > >Over the next week, I'll have some time to get to a handful of them. > >Anyway, has your class been using Convey? I realize it's only a week or two >into the semester. But, have you had a chance to use it for real? > >Andy > >-----Original Message----- >From: con...@li... >[mailto:con...@li...]On Behalf Of Andy >Ames >Sent: Monday, August 25, 2003 6:52 PM >To: con...@li... >Subject: RE: [convey-developers] convey 0.4? > > >Ed, Scott, > >I'm married and off to Thailand tomorrow! We're packing now. We'll be back >in two weeks on 9/10. > >Real quick, I like the ideas you presented in your last email, Scott. >Specifically, the broadcasting p-2-p chatroom. > >I won't have time to comment further before leaving. I would certainly like >to meet with you two when I return. > >Enjoy the rest of your summers. > >Andy > >-----Original Message----- >From: con...@li... >[mailto:con...@li...]On Behalf Of Scott >Luan >Sent: Saturday, August 23, 2003 10:12 PM >To: con...@li... >Subject: [convey-developers] convey 0.4? > > >Hi Ed, Andy, > >Thanks for the update Ed. > >I have tried out the latest Convey. It looks great! Good work guys! > >I especially enjoyed the tabbed canvases, the pen mode operations of >yield/revoke/request, and the auto-send toggle. The layout of the features >and buttons is convienent. > >Well, as for me, I have **finally** finished my cOmPiLeR! It generates >unoptimized assembly code for the x86 and SPARC and supports basic OO >features. Whew... that took a good part of the summer. Now for what's >left >of it, I'll be leaving for Japan on Monday and returning mid-September. > >Have a great few(?) weeks before school starts! :-) > >Take care, >Scott > >_________________________________________________________________ >MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup > > > >------------------------------------------------------- >This SF.net email is sponsored by: VM Ware >With VMware you can run multiple operating systems on a single machine. >WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines >at the same time. Free trial click >here:http://www.vmware.com/wl/offer/358/0 >_______________________________________________ >convey-developers mailing list >con...@li... >https://lists.sourceforge.net/lists/listinfo/convey-developers > > > >------------------------------------------------------- >This SF.net email is sponsored by: VM Ware >With VMware you can run multiple operating systems on a single machine. >WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines >at the same time. Free trial click >here:http://www.vmware.com/wl/offer/358/0 >_______________________________________________ >convey-developers mailing list >con...@li... >https://lists.sourceforge.net/lists/listinfo/convey-developers > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >convey-developers mailing list >con...@li... >https://lists.sourceforge.net/lists/listinfo/convey-developers _________________________________________________________________ Instant message in style with MSN Messenger 6.0. Download it now FREE! http://msnmessenger-download.com |
|
From: Andy A. <ag...@sb...> - 2003-09-13 21:49:18
|
Hi, Ed and Scott, I returned from Thailand only to get sick the day I got off the plane. At least I wasn't sick while I was there. Ed, out of the bugs you've submitted regarding Convey Java, can you go set there priority values to reflect their importance. Give anything that has been an showstopper a 9 priority. Bugs that have been somewhat of an annoyance, give them an 8. Over the next week, I'll have some time to get to a handful of them. Anyway, has your class been using Convey? I realize it's only a week or two into the semester. But, have you had a chance to use it for real? Andy -----Original Message----- From: con...@li... [mailto:con...@li...]On Behalf Of Andy Ames Sent: Monday, August 25, 2003 6:52 PM To: con...@li... Subject: RE: [convey-developers] convey 0.4? Ed, Scott, I'm married and off to Thailand tomorrow! We're packing now. We'll be back in two weeks on 9/10. Real quick, I like the ideas you presented in your last email, Scott. Specifically, the broadcasting p-2-p chatroom. I won't have time to comment further before leaving. I would certainly like to meet with you two when I return. Enjoy the rest of your summers. Andy -----Original Message----- From: con...@li... [mailto:con...@li...]On Behalf Of Scott Luan Sent: Saturday, August 23, 2003 10:12 PM To: con...@li... Subject: [convey-developers] convey 0.4? Hi Ed, Andy, Thanks for the update Ed. I have tried out the latest Convey. It looks great! Good work guys! I especially enjoyed the tabbed canvases, the pen mode operations of yield/revoke/request, and the auto-send toggle. The layout of the features and buttons is convienent. Well, as for me, I have **finally** finished my cOmPiLeR! It generates unoptimized assembly code for the x86 and SPARC and supports basic OO features. Whew... that took a good part of the summer. Now for what's left of it, I'll be leaving for Japan on Monday and returning mid-September. Have a great few(?) weeks before school starts! :-) Take care, Scott _________________________________________________________________ MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ convey-developers mailing list con...@li... https://lists.sourceforge.net/lists/listinfo/convey-developers ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ convey-developers mailing list con...@li... https://lists.sourceforge.net/lists/listinfo/convey-developers |
|
From: Andy A. <ag...@sb...> - 2003-08-26 01:51:49
|
Ed, Scott, I'm married and off to Thailand tomorrow! We're packing now. We'll be back in two weeks on 9/10. Real quick, I like the ideas you presented in your last email, Scott. Specifically, the broadcasting p-2-p chatroom. I won't have time to comment further before leaving. I would certainly like to meet with you two when I return. Enjoy the rest of your summers. Andy -----Original Message----- From: con...@li... [mailto:con...@li...]On Behalf Of Scott Luan Sent: Saturday, August 23, 2003 10:12 PM To: con...@li... Subject: [convey-developers] convey 0.4? Hi Ed, Andy, Thanks for the update Ed. I have tried out the latest Convey. It looks great! Good work guys! I especially enjoyed the tabbed canvases, the pen mode operations of yield/revoke/request, and the auto-send toggle. The layout of the features and buttons is convienent. Well, as for me, I have **finally** finished my cOmPiLeR! It generates unoptimized assembly code for the x86 and SPARC and supports basic OO features. Whew... that took a good part of the summer. Now for what's left of it, I'll be leaving for Japan on Monday and returning mid-September. Have a great few(?) weeks before school starts! :-) Take care, Scott _________________________________________________________________ MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 _______________________________________________ convey-developers mailing list con...@li... https://lists.sourceforge.net/lists/listinfo/convey-developers |
|
From: Scott L. <sco...@ho...> - 2003-08-24 05:11:50
|
Hi Ed, Andy, Thanks for the update Ed. I have tried out the latest Convey. It looks great! Good work guys! I especially enjoyed the tabbed canvases, the pen mode operations of yield/revoke/request, and the auto-send toggle. The layout of the features and buttons is convienent. Well, as for me, I have **finally** finished my cOmPiLeR! It generates unoptimized assembly code for the x86 and SPARC and supports basic OO features. Whew... that took a good part of the summer. Now for what's left of it, I'll be leaving for Japan on Monday and returning mid-September. Have a great few(?) weeks before school starts! :-) Take care, Scott _________________________________________________________________ MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup |
|
From: Scott L. <sco...@ho...> - 2003-08-20 07:56:53
|
Andy, I really like your idea about an OOD for the client which may be suitable for the different possible implementations. Not only will this approach motivate us, but also it may be technically advantageous. With a convienent OOD we can rework/resuse the existing code without much hair-pulling. I suspect that in going from a thick to thin Convey on Jabber, there would be significant code migration from the client to the server side. Therefore, perhaps, a significant portion of the JEP would come from the OOD. Yes, I agree, backing into corners should be avoided. And speaking of corners, there's a bit of a catch, I believe, if a client is required to play the host (or pseudo-server) to address the problem of updating new participants with the XML document. This would stray from a p-2-p capability which I hope would be inherent in the design. An alternative would be to broadcast a chatroom (or in search of a chatroom) and accept the first response, and perhaps ignoring the rest.. Clients of different chatrooms would propagate the search request. A desired client would respond with a preliminary handshake or immediately send off the whole document. Even though this smells like p-2-p, it can be compatible within a Jabber framework of public/private messages. A secondary effect of this method would be that it ensures the update is timely -- the new participant would be updated by the fastest client. However, it wouldn't completely solve potential problems which may arise during the initial start-up time. One obvious problem may arise from the possibility that diff messages may be lost while waiting to obtain the whole XML document. To compensate, a new participant may simply accept diff messages even before it has the complete document; the resolution may be deferred. Another approach may be to have a new participant send requests for the document certain number of times until it has concluded that the document has stabilized. Anyway, just things to consider. Scott >From: "Andy Ames" <ag...@sb...> >Reply-To: con...@li... >To: <con...@li...> >Subject: RE: [convey-developers] JEP - Collaborative XML Document Editing >Date: Mon, 18 Aug 2003 19:59:31 -0700 > >Scott, > >Okay. I'm starting to see all the various ways we can implement Convey. >I'll >try to organize and summarize each implementation here, using terms that >we've coined. My intention is that this will help us talk about Convey. > >1) Thick client Convey: this would be least dependent on a server and most >autonomous of the implementations. I see two possible subcategories of a >thick client implementation: > >a) Thick client Convey via Jabber (centralized p-2-p): this would use the >existing Jabber infrastructure (client/server) for XML edits. However, >every >client would store and manage its own >copy of the XML doc. This scenario applies to both one-on-one chats and >conference chats. This implementation also warrants our pseudo-server; >where >one chat participant acts as the host in that it sends newly connecting >members the current XML doc. Note that we don't need to develop or maintain >our own server, so long as Jabber continues to remain active. If Jabber >goes >inactive, then us or other companies will have to run a server. > >b) Thick client Convey (decentralized p-2-p): This is very similar in >nature >and use cases as implementation (1a), it just doesn't use Jabber. There >would still need to be hosts responsible for updating new participants of >the existing XML doc. Clients would still store and manage a copy of the >XML >doc. > >2) Thin client Convey (client/server): This requires us to develop and >maintain a server. Again, I see two subcategories: > >a) Thin client via Jabber: Here, we write a Jabber server component plugin. >This plugin will store the XML doc on a server and perform concurrency >resolution. Of course, it can be configured by admins to require admin >intervention upon concurrency conflicts. > >b) Thin client: Here, we write our own client/server protocol and develop a >server. We could base the server on existing Jabber code--perhaps reuse the >Jabber Session Manager (JSM) for client connections, and so on. > >So, we have a matrix of possibilities: > > | Jabber | Custom >------------------------ >Thick | 1a | 1b >------------------------ >Thin | 2a | 2b > >An interesting thing to note is that we also can have 1c, 2c, 1d, 2d..., >depending on if we want to consider other technologies. > >Is this accurate? > >It is certainly feasible to implement the Convey client with all of these >implementation scenarios. That way, we can ensure an OOD for the client >that >wont back us into a corner. Not only that, it lets us all develop Convey, >knowing that we will have an implementation that suits our own personal >desires. > >Ed, can have his implementation for distance education. If he wants server >side tracking of sessions and hours (as is common for a public education >institution), then he can implement it as needed. > >Scott, you can have a decentralized p-2-p implementation. > >I can have an IM-centric implementation, complete with buddy lists and so >on. > >What do you think? > >Andy > >-----Original Message----- >From: con...@li... >[mailto:con...@li...]On Behalf Of Scott >Luan >Sent: Monday, August 18, 2003 4:56 PM >To: con...@li... >Subject: RE: [convey-developers] JEP - Collaborative XML Document >Editing > > >Andy, > >Thanks for your response. > >Instead of "IM", a better phrase would be "centralized p-2-p" which is >based >on the server-client architecture. This stands in contrast to a >"decentralized p-2-p" (or just plain p-2-p) for client-client >communication. > >The specific limitation for Convey on Jabber, as I was thinking, and as you >pointed out, is not the actual XML format of the messages, but rather the >server-client paradigm itself. As you said, however, it may be adequate >for >the expected use-cases. . > >Collaboratively editing a shared set of data may be applicable to >situations >in which the clients may be in an isolated LAN or may not want to be >dependent on the reliability of a server. I admit that this would >probably not apply to most users of Convey as an e-learning and user >collaboration tool. Perhaps, my interest in a thick-client on p-2-p is >merely academic and relates to more exotic uses. > >Nevertheless, I suspect that adapting the thick-client Jabber version of >Convey for some p-2-p protocol may require less rework than making Convey >thinner. But I agree with you that a thin-client version of Convey using a >Jabber-extension may be well justified given the use-cases you provided. > >Scott > > >From: "Andy Ames" <ag...@sb...> > >Reply-To: con...@li... > >To: <con...@li...> > >Subject: RE: [convey-developers] JEP - Collaborative XML Document Editing > >Date: Sun, 17 Aug 2003 21:57:28 -0700 > > > >Hi, > > > >Comments embedded below. > > > > > -----Original Message----- > > > From: con...@li... > > > [mailto:con...@li...]On Behalf Of >Scott > > > Luan > > > Sent: Sunday, August 17, 2003 4:13 PM > > > To: con...@li... > > > Subject: Re: [convey-developers] JEP - Collaborative XML Document > > > Editing > > > > > I think the JEP title "Collaborative XML Document Editing" is a >telling > >one. > > > It is good because it captures a lot of what we have been >discussing. > >The > > > unit of focus is an "XML document", and this implies a measure of > > > extenibility to derivative specs such as SVG, MathML, etc. Also, > >"editing" > > > is the core of the problem which subsumes questions about concurrency, > > > canvas resolution schemes, and, > > > inevitably, about essential architectural details (i.e. the location >of > >the > > > document). Furthermore, the title emphasizes the primay goal of > >achieving > >a > > > way to "collaborate". This may be accomplished by using an IM >protocol > > > such as Jabber. > > > > > (Let me be straightforward, and pardon me if I sound too blunt.) > > > > > However, I see great potential in Convey which transcends the > >limitations > >of > > > Instant Messaging, the primary one being that a central server is > >necessary. > > > Writing a client for Jabber may be necessary for a wide variety of > >good > > > reasons. However, I think that to have the design of Convey >influenced > >and > > > constrained by JSF and its guidelines may run counter to the >fundamental > > > reasons of why I am excited about this project. Its potential greatly > > > appeals to me. > > > > > What is its potential? Its potential to transact in XML rather than a > > > specific grammar of XML (ie. SVG), as we discussed, increases its > > > applicability. > > > >I agree completely. We should focus on an XML-centered data view. All > >collaborative conversations consist of an XML document. All elements of >the > >conversation are done in XML. This includes the history of changes to a > >document, the document itself, and so on. > > > > > There is another potential which I want to highlight. I think there >is > >a > > > way to design Convey so that it is compatible with IM protocols like > >Jabber > > > and also decentralized P-2-P protocols (which currently may have >aspects > > > that still problematic, but its promise is captivating). Convey has > >great > > > potential to be adaptable in this way -- of not being limited to or > > > dependent on a specific kind of collaborative technology. > > > >IMO, P-2-P is not important. Actually, it's not important to me because >of > >the relative difficulty in solving the problems inherent with P-2-P. >These > >may be the problems you alluded to (firewalls). > > > >This may be short-sighted of me, but I don't see any application of >Convey > >or collaborative XML document editing that cannot be done in a > >client/server > >paradigm. > > > >The use cases that I focus on are 1) one-on-one tutoring through an >online > >learning center, 2) company business communications and collaborations, >3) > >group instruction, and 4) friend-to-friend collaborations. > > > >Each of these use cases can be solved without going P-2-P. Am I missing >any > >important use cases? > > > > > A Convey which works with Jabber may use only its basic requirements >of > > > sending, receiving, login, etc; no extensions would be necessary. It > >is > > > client-heavy because it uses the server only to relay messages. All > >other > > > tasks are its responsibility. > > > >This should be our first implementation of Convey. The first >implementation > >should require no modifications to a Jabber server for it to work. Like >you > >said, client-heavy. > > > >However, the trend of internet tecnology is toward server-heavy from > >client-heavy. This has been the trend ever since the internet boom began. > >Most would agree that this trend is not going to change, now that >everyone > >is going mobile. > > > >I would only want a client-heavy Convey as a stepping stone toward > >server-heavy. I wouldn't want client-heavy as the desired implementation. > > > > > But writing a JEP may be worthwhile for many reasons. However, in my > > > thinking, the persuasive force of Convey resides outside of the Jabber > > > world. Jabber, like expat and wxWindows, is an enabling component for > > > Convey. The core of Convey, also in my thinking, and perhaps in yours > >too, > > > is how it addresses concurrency issues to allow for collaborative > >editing > >of > > > XML documents. > > > >One thing I want to point out is that Jabber does not in any way limit >and > >restrict the implementation of our messaging formats. Jabber is a meta > >protocol. The design philosophy of Jabber was that it posed no >restrictions > >on the nature of the XML data it transmits. > > > >There are Jabber extensions for all sorts of applications. One notable > >example, is Jabber XML-RPC. One can write a Jabber client that automates >a > >remote Component (DCOM, Corba, EJB). > > > >If we use Jabber, we have complete control over the format of the data we > >transmit, as long as it's XML. That's why the call it _eXtensbile_ > >Messaging > >and Presence Protocol (XMPP). > > > >Of course, if we want a server to step in and do anything, we need to >write > >a custom Jabber component. If we stay client-heavy, we never need to do > >this. > > > >As for a JEP, no one implements a JEP until it has gone through at least >a > >year of peer review, except for the original authors. The reason I'd like > >to > >write one, is its the expected method of communicating with the Jabber > >community our intentions, so that they can peer review our work. > > > >The JEP authors usually are the only ones implementing the JEP at first. > >Then, once the JEP has been accepted, others may jump on the bandwagon >and > >implement a Jabber client that supports whatever the JEP adds. But, they > >don't have to. Just like Convey never has to have a buddy list or post > >presence information. > > > >Another thing I want to point out, is that Jabber is NOT an IM system. I > >have been referring to Jabber as an IM system in err. IM is just the most > >common use it's put to. XML-RPC is justification for the validity that > >Jabber is not only an IM system. > > > >Here's where I stand on the topic, if we a) decide to go Jabber, and b) > >want > >the community to peer review us, then we write a JEP to facilitate the >peer > >review. > > > >OTOH, if we don't go Jabber, we must justify to ourselves the value of >this > >choice. Currently, I do not see the justification since the design of > >Jabber > >was to provide a framework for doing what we're trying to do. > > > >To aid in this decision, we must define the requirements of the system we > >want to design and implement. If Jabber falls short of these >requirements, > >then we do not use it. Of course, I'm sure this won't be that simple. > >Jabber > >may meet all requirements but a few. If that's the case, then we can > >consider a server extension. > > > >(BTW, we can choose to use the Jabber server and protocol, and decide we > >don't care about interoperability with other Jabbers users and IM >systems. > >In this case, we'd just be using Jabber as a springboard into our own > >custom > >implementation.) > > > >Andy > > > ><snip> > > > > > > > >------------------------------------------------------- > >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 > >_________________________________________________________________ ><b>Get MSN 8</b> and help protect your children with advanced parental >controls. http://join.msn.com/?page=features/parental > > > >------------------------------------------------------- >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 _________________________________________________________________ <b>Get MSN 8</b> and help protect your children with advanced parental controls. http://join.msn.com/?page=features/parental |
|
From: Andy A. <ag...@sb...> - 2003-08-19 02:59:38
|
Scott,
Okay. I'm starting to see all the various ways we can implement Convey. I'll
try to organize and summarize each implementation here, using terms that
we've coined. My intention is that this will help us talk about Convey.
1) Thick client Convey: this would be least dependent on a server and most
autonomous of the implementations. I see two possible subcategories of a
thick client implementation:
a) Thick client Convey via Jabber (centralized p-2-p): this would use the
existing Jabber infrastructure (client/server) for XML edits. However, every
client would store and manage its own
copy of the XML doc. This scenario applies to both one-on-one chats and
conference chats. This implementation also warrants our pseudo-server; where
one chat participant acts as the host in that it sends newly connecting
members the current XML doc. Note that we don't need to develop or maintain
our own server, so long as Jabber continues to remain active. If Jabber goes
inactive, then us or other companies will have to run a server.
b) Thick client Convey (decentralized p-2-p): This is very similar in nature
and use cases as implementation (1a), it just doesn't use Jabber. There
would still need to be hosts responsible for updating new participants of
the existing XML doc. Clients would still store and manage a copy of the XML
doc.
2) Thin client Convey (client/server): This requires us to develop and
maintain a server. Again, I see two subcategories:
a) Thin client via Jabber: Here, we write a Jabber server component plugin.
This plugin will store the XML doc on a server and perform concurrency
resolution. Of course, it can be configured by admins to require admin
intervention upon concurrency conflicts.
b) Thin client: Here, we write our own client/server protocol and develop a
server. We could base the server on existing Jabber code--perhaps reuse the
Jabber Session Manager (JSM) for client connections, and so on.
So, we have a matrix of possibilities:
| Jabber | Custom
------------------------
Thick | 1a | 1b
------------------------
Thin | 2a | 2b
An interesting thing to note is that we also can have 1c, 2c, 1d, 2d...,
depending on if we want to consider other technologies.
Is this accurate?
It is certainly feasible to implement the Convey client with all of these
implementation scenarios. That way, we can ensure an OOD for the client that
wont back us into a corner. Not only that, it lets us all develop Convey,
knowing that we will have an implementation that suits our own personal
desires.
Ed, can have his implementation for distance education. If he wants server
side tracking of sessions and hours (as is common for a public education
institution), then he can implement it as needed.
Scott, you can have a decentralized p-2-p implementation.
I can have an IM-centric implementation, complete with buddy lists and so
on.
What do you think?
Andy
-----Original Message-----
From: con...@li...
[mailto:con...@li...]On Behalf Of Scott
Luan
Sent: Monday, August 18, 2003 4:56 PM
To: con...@li...
Subject: RE: [convey-developers] JEP - Collaborative XML Document
Editing
Andy,
Thanks for your response.
Instead of "IM", a better phrase would be "centralized p-2-p" which is based
on the server-client architecture. This stands in contrast to a
"decentralized p-2-p" (or just plain p-2-p) for client-client communication.
The specific limitation for Convey on Jabber, as I was thinking, and as you
pointed out, is not the actual XML format of the messages, but rather the
server-client paradigm itself. As you said, however, it may be adequate for
the expected use-cases. .
Collaboratively editing a shared set of data may be applicable to situations
in which the clients may be in an isolated LAN or may not want to be
dependent on the reliability of a server. I admit that this would
probably not apply to most users of Convey as an e-learning and user
collaboration tool. Perhaps, my interest in a thick-client on p-2-p is
merely academic and relates to more exotic uses.
Nevertheless, I suspect that adapting the thick-client Jabber version of
Convey for some p-2-p protocol may require less rework than making Convey
thinner. But I agree with you that a thin-client version of Convey using a
Jabber-extension may be well justified given the use-cases you provided.
Scott
>From: "Andy Ames" <ag...@sb...>
>Reply-To: con...@li...
>To: <con...@li...>
>Subject: RE: [convey-developers] JEP - Collaborative XML Document Editing
>Date: Sun, 17 Aug 2003 21:57:28 -0700
>
>Hi,
>
>Comments embedded below.
>
> > -----Original Message-----
> > From: con...@li...
> > [mailto:con...@li...]On Behalf Of Scott
> > Luan
> > Sent: Sunday, August 17, 2003 4:13 PM
> > To: con...@li...
> > Subject: Re: [convey-developers] JEP - Collaborative XML Document
> > Editing
>
> > I think the JEP title "Collaborative XML Document Editing" is a telling
>one.
> > It is good because it captures a lot of what we have been discussing.
>The
> > unit of focus is an "XML document", and this implies a measure of
> > extenibility to derivative specs such as SVG, MathML, etc. Also,
>"editing"
> > is the core of the problem which subsumes questions about concurrency,
> > canvas resolution schemes, and,
> > inevitably, about essential architectural details (i.e. the location of
>the
> > document). Furthermore, the title emphasizes the primay goal of
>achieving
>a
> > way to "collaborate". This may be accomplished by using an IM protocol
> > such as Jabber.
>
> > (Let me be straightforward, and pardon me if I sound too blunt.)
>
> > However, I see great potential in Convey which transcends the
>limitations
>of
> > Instant Messaging, the primary one being that a central server is
>necessary.
> > Writing a client for Jabber may be necessary for a wide variety of
>good
> > reasons. However, I think that to have the design of Convey influenced
>and
> > constrained by JSF and its guidelines may run counter to the fundamental
> > reasons of why I am excited about this project. Its potential greatly
> > appeals to me.
>
> > What is its potential? Its potential to transact in XML rather than a
> > specific grammar of XML (ie. SVG), as we discussed, increases its
> > applicability.
>
>I agree completely. We should focus on an XML-centered data view. All
>collaborative conversations consist of an XML document. All elements of the
>conversation are done in XML. This includes the history of changes to a
>document, the document itself, and so on.
>
> > There is another potential which I want to highlight. I think there is
>a
> > way to design Convey so that it is compatible with IM protocols like
>Jabber
> > and also decentralized P-2-P protocols (which currently may have aspects
> > that still problematic, but its promise is captivating). Convey has
>great
> > potential to be adaptable in this way -- of not being limited to or
> > dependent on a specific kind of collaborative technology.
>
>IMO, P-2-P is not important. Actually, it's not important to me because of
>the relative difficulty in solving the problems inherent with P-2-P. These
>may be the problems you alluded to (firewalls).
>
>This may be short-sighted of me, but I don't see any application of Convey
>or collaborative XML document editing that cannot be done in a
>client/server
>paradigm.
>
>The use cases that I focus on are 1) one-on-one tutoring through an online
>learning center, 2) company business communications and collaborations, 3)
>group instruction, and 4) friend-to-friend collaborations.
>
>Each of these use cases can be solved without going P-2-P. Am I missing any
>important use cases?
>
> > A Convey which works with Jabber may use only its basic requirements of
> > sending, receiving, login, etc; no extensions would be necessary. It
>is
> > client-heavy because it uses the server only to relay messages. All
>other
> > tasks are its responsibility.
>
>This should be our first implementation of Convey. The first implementation
>should require no modifications to a Jabber server for it to work. Like you
>said, client-heavy.
>
>However, the trend of internet tecnology is toward server-heavy from
>client-heavy. This has been the trend ever since the internet boom began.
>Most would agree that this trend is not going to change, now that everyone
>is going mobile.
>
>I would only want a client-heavy Convey as a stepping stone toward
>server-heavy. I wouldn't want client-heavy as the desired implementation.
>
> > But writing a JEP may be worthwhile for many reasons. However, in my
> > thinking, the persuasive force of Convey resides outside of the Jabber
> > world. Jabber, like expat and wxWindows, is an enabling component for
> > Convey. The core of Convey, also in my thinking, and perhaps in yours
>too,
> > is how it addresses concurrency issues to allow for collaborative
>editing
>of
> > XML documents.
>
>One thing I want to point out is that Jabber does not in any way limit and
>restrict the implementation of our messaging formats. Jabber is a meta
>protocol. The design philosophy of Jabber was that it posed no restrictions
>on the nature of the XML data it transmits.
>
>There are Jabber extensions for all sorts of applications. One notable
>example, is Jabber XML-RPC. One can write a Jabber client that automates a
>remote Component (DCOM, Corba, EJB).
>
>If we use Jabber, we have complete control over the format of the data we
>transmit, as long as it's XML. That's why the call it _eXtensbile_
>Messaging
>and Presence Protocol (XMPP).
>
>Of course, if we want a server to step in and do anything, we need to write
>a custom Jabber component. If we stay client-heavy, we never need to do
>this.
>
>As for a JEP, no one implements a JEP until it has gone through at least a
>year of peer review, except for the original authors. The reason I'd like
>to
>write one, is its the expected method of communicating with the Jabber
>community our intentions, so that they can peer review our work.
>
>The JEP authors usually are the only ones implementing the JEP at first.
>Then, once the JEP has been accepted, others may jump on the bandwagon and
>implement a Jabber client that supports whatever the JEP adds. But, they
>don't have to. Just like Convey never has to have a buddy list or post
>presence information.
>
>Another thing I want to point out, is that Jabber is NOT an IM system. I
>have been referring to Jabber as an IM system in err. IM is just the most
>common use it's put to. XML-RPC is justification for the validity that
>Jabber is not only an IM system.
>
>Here's where I stand on the topic, if we a) decide to go Jabber, and b)
>want
>the community to peer review us, then we write a JEP to facilitate the peer
>review.
>
>OTOH, if we don't go Jabber, we must justify to ourselves the value of this
>choice. Currently, I do not see the justification since the design of
>Jabber
>was to provide a framework for doing what we're trying to do.
>
>To aid in this decision, we must define the requirements of the system we
>want to design and implement. If Jabber falls short of these requirements,
>then we do not use it. Of course, I'm sure this won't be that simple.
>Jabber
>may meet all requirements but a few. If that's the case, then we can
>consider a server extension.
>
>(BTW, we can choose to use the Jabber server and protocol, and decide we
>don't care about interoperability with other Jabbers users and IM systems.
>In this case, we'd just be using Jabber as a springboard into our own
>custom
>implementation.)
>
>Andy
>
><snip>
>
>
>
>-------------------------------------------------------
>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
_________________________________________________________________
<b>Get MSN 8</b> and help protect your children with advanced parental
controls. http://join.msn.com/?page=features/parental
-------------------------------------------------------
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-18 23:56:21
|
Andy, Thanks for your response. Instead of "IM", a better phrase would be "centralized p-2-p" which is based on the server-client architecture. This stands in contrast to a "decentralized p-2-p" (or just plain p-2-p) for client-client communication. The specific limitation for Convey on Jabber, as I was thinking, and as you pointed out, is not the actual XML format of the messages, but rather the server-client paradigm itself. As you said, however, it may be adequate for the expected use-cases. . Collaboratively editing a shared set of data may be applicable to situations in which the clients may be in an isolated LAN or may not want to be dependent on the reliability of a server. I admit that this would probably not apply to most users of Convey as an e-learning and user collaboration tool. Perhaps, my interest in a thick-client on p-2-p is merely academic and relates to more exotic uses. Nevertheless, I suspect that adapting the thick-client Jabber version of Convey for some p-2-p protocol may require less rework than making Convey thinner. But I agree with you that a thin-client version of Convey using a Jabber-extension may be well justified given the use-cases you provided. Scott >From: "Andy Ames" <ag...@sb...> >Reply-To: con...@li... >To: <con...@li...> >Subject: RE: [convey-developers] JEP - Collaborative XML Document Editing >Date: Sun, 17 Aug 2003 21:57:28 -0700 > >Hi, > >Comments embedded below. > > > -----Original Message----- > > From: con...@li... > > [mailto:con...@li...]On Behalf Of Scott > > Luan > > Sent: Sunday, August 17, 2003 4:13 PM > > To: con...@li... > > Subject: Re: [convey-developers] JEP - Collaborative XML Document > > Editing > > > I think the JEP title "Collaborative XML Document Editing" is a telling >one. > > It is good because it captures a lot of what we have been discussing. >The > > unit of focus is an "XML document", and this implies a measure of > > extenibility to derivative specs such as SVG, MathML, etc. Also, >"editing" > > is the core of the problem which subsumes questions about concurrency, > > canvas resolution schemes, and, > > inevitably, about essential architectural details (i.e. the location of >the > > document). Furthermore, the title emphasizes the primay goal of >achieving >a > > way to "collaborate". This may be accomplished by using an IM protocol > > such as Jabber. > > > (Let me be straightforward, and pardon me if I sound too blunt.) > > > However, I see great potential in Convey which transcends the >limitations >of > > Instant Messaging, the primary one being that a central server is >necessary. > > Writing a client for Jabber may be necessary for a wide variety of >good > > reasons. However, I think that to have the design of Convey influenced >and > > constrained by JSF and its guidelines may run counter to the fundamental > > reasons of why I am excited about this project. Its potential greatly > > appeals to me. > > > What is its potential? Its potential to transact in XML rather than a > > specific grammar of XML (ie. SVG), as we discussed, increases its > > applicability. > >I agree completely. We should focus on an XML-centered data view. All >collaborative conversations consist of an XML document. All elements of the >conversation are done in XML. This includes the history of changes to a >document, the document itself, and so on. > > > There is another potential which I want to highlight. I think there is >a > > way to design Convey so that it is compatible with IM protocols like >Jabber > > and also decentralized P-2-P protocols (which currently may have aspects > > that still problematic, but its promise is captivating). Convey has >great > > potential to be adaptable in this way -- of not being limited to or > > dependent on a specific kind of collaborative technology. > >IMO, P-2-P is not important. Actually, it's not important to me because of >the relative difficulty in solving the problems inherent with P-2-P. These >may be the problems you alluded to (firewalls). > >This may be short-sighted of me, but I don't see any application of Convey >or collaborative XML document editing that cannot be done in a >client/server >paradigm. > >The use cases that I focus on are 1) one-on-one tutoring through an online >learning center, 2) company business communications and collaborations, 3) >group instruction, and 4) friend-to-friend collaborations. > >Each of these use cases can be solved without going P-2-P. Am I missing any >important use cases? > > > A Convey which works with Jabber may use only its basic requirements of > > sending, receiving, login, etc; no extensions would be necessary. It >is > > client-heavy because it uses the server only to relay messages. All >other > > tasks are its responsibility. > >This should be our first implementation of Convey. The first implementation >should require no modifications to a Jabber server for it to work. Like you >said, client-heavy. > >However, the trend of internet tecnology is toward server-heavy from >client-heavy. This has been the trend ever since the internet boom began. >Most would agree that this trend is not going to change, now that everyone >is going mobile. > >I would only want a client-heavy Convey as a stepping stone toward >server-heavy. I wouldn't want client-heavy as the desired implementation. > > > But writing a JEP may be worthwhile for many reasons. However, in my > > thinking, the persuasive force of Convey resides outside of the Jabber > > world. Jabber, like expat and wxWindows, is an enabling component for > > Convey. The core of Convey, also in my thinking, and perhaps in yours >too, > > is how it addresses concurrency issues to allow for collaborative >editing >of > > XML documents. > >One thing I want to point out is that Jabber does not in any way limit and >restrict the implementation of our messaging formats. Jabber is a meta >protocol. The design philosophy of Jabber was that it posed no restrictions >on the nature of the XML data it transmits. > >There are Jabber extensions for all sorts of applications. One notable >example, is Jabber XML-RPC. One can write a Jabber client that automates a >remote Component (DCOM, Corba, EJB). > >If we use Jabber, we have complete control over the format of the data we >transmit, as long as it's XML. That's why the call it _eXtensbile_ >Messaging >and Presence Protocol (XMPP). > >Of course, if we want a server to step in and do anything, we need to write >a custom Jabber component. If we stay client-heavy, we never need to do >this. > >As for a JEP, no one implements a JEP until it has gone through at least a >year of peer review, except for the original authors. The reason I'd like >to >write one, is its the expected method of communicating with the Jabber >community our intentions, so that they can peer review our work. > >The JEP authors usually are the only ones implementing the JEP at first. >Then, once the JEP has been accepted, others may jump on the bandwagon and >implement a Jabber client that supports whatever the JEP adds. But, they >don't have to. Just like Convey never has to have a buddy list or post >presence information. > >Another thing I want to point out, is that Jabber is NOT an IM system. I >have been referring to Jabber as an IM system in err. IM is just the most >common use it's put to. XML-RPC is justification for the validity that >Jabber is not only an IM system. > >Here's where I stand on the topic, if we a) decide to go Jabber, and b) >want >the community to peer review us, then we write a JEP to facilitate the peer >review. > >OTOH, if we don't go Jabber, we must justify to ourselves the value of this >choice. Currently, I do not see the justification since the design of >Jabber >was to provide a framework for doing what we're trying to do. > >To aid in this decision, we must define the requirements of the system we >want to design and implement. If Jabber falls short of these requirements, >then we do not use it. Of course, I'm sure this won't be that simple. >Jabber >may meet all requirements but a few. If that's the case, then we can >consider a server extension. > >(BTW, we can choose to use the Jabber server and protocol, and decide we >don't care about interoperability with other Jabbers users and IM systems. >In this case, we'd just be using Jabber as a springboard into our own >custom >implementation.) > >Andy > ><snip> > > > >------------------------------------------------------- >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 _________________________________________________________________ <b>Get MSN 8</b> and help protect your children with advanced parental controls. http://join.msn.com/?page=features/parental |
|
From: Andy A. <ag...@sb...> - 2003-08-18 04:58:05
|
Hi, Comments embedded below. > -----Original Message----- > From: con...@li... > [mailto:con...@li...]On Behalf Of Scott > Luan > Sent: Sunday, August 17, 2003 4:13 PM > To: con...@li... > Subject: Re: [convey-developers] JEP - Collaborative XML Document > Editing > I think the JEP title "Collaborative XML Document Editing" is a telling one. > It is good because it captures a lot of what we have been discussing. The > unit of focus is an "XML document", and this implies a measure of > extenibility to derivative specs such as SVG, MathML, etc. Also, "editing" > is the core of the problem which subsumes questions about concurrency, > canvas resolution schemes, and, > inevitably, about essential architectural details (i.e. the location of the > document). Furthermore, the title emphasizes the primay goal of achieving a > way to "collaborate". This may be accomplished by using an IM protocol > such as Jabber. > (Let me be straightforward, and pardon me if I sound too blunt.) > However, I see great potential in Convey which transcends the limitations of > Instant Messaging, the primary one being that a central server is necessary. > Writing a client for Jabber may be necessary for a wide variety of good > reasons. However, I think that to have the design of Convey influenced and > constrained by JSF and its guidelines may run counter to the fundamental > reasons of why I am excited about this project. Its potential greatly > appeals to me. > What is its potential? Its potential to transact in XML rather than a > specific grammar of XML (ie. SVG), as we discussed, increases its > applicability. I agree completely. We should focus on an XML-centered data view. All collaborative conversations consist of an XML document. All elements of the conversation are done in XML. This includes the history of changes to a document, the document itself, and so on. > There is another potential which I want to highlight. I think there is a > way to design Convey so that it is compatible with IM protocols like Jabber > and also decentralized P-2-P protocols (which currently may have aspects > that still problematic, but its promise is captivating). Convey has great > potential to be adaptable in this way -- of not being limited to or > dependent on a specific kind of collaborative technology. IMO, P-2-P is not important. Actually, it's not important to me because of the relative difficulty in solving the problems inherent with P-2-P. These may be the problems you alluded to (firewalls). This may be short-sighted of me, but I don't see any application of Convey or collaborative XML document editing that cannot be done in a client/server paradigm. The use cases that I focus on are 1) one-on-one tutoring through an online learning center, 2) company business communications and collaborations, 3) group instruction, and 4) friend-to-friend collaborations. Each of these use cases can be solved without going P-2-P. Am I missing any important use cases? > A Convey which works with Jabber may use only its basic requirements of > sending, receiving, login, etc; no extensions would be necessary. It is > client-heavy because it uses the server only to relay messages. All other > tasks are its responsibility. This should be our first implementation of Convey. The first implementation should require no modifications to a Jabber server for it to work. Like you said, client-heavy. However, the trend of internet tecnology is toward server-heavy from client-heavy. This has been the trend ever since the internet boom began. Most would agree that this trend is not going to change, now that everyone is going mobile. I would only want a client-heavy Convey as a stepping stone toward server-heavy. I wouldn't want client-heavy as the desired implementation. > But writing a JEP may be worthwhile for many reasons. However, in my > thinking, the persuasive force of Convey resides outside of the Jabber > world. Jabber, like expat and wxWindows, is an enabling component for > Convey. The core of Convey, also in my thinking, and perhaps in yours too, > is how it addresses concurrency issues to allow for collaborative editing of > XML documents. One thing I want to point out is that Jabber does not in any way limit and restrict the implementation of our messaging formats. Jabber is a meta protocol. The design philosophy of Jabber was that it posed no restrictions on the nature of the XML data it transmits. There are Jabber extensions for all sorts of applications. One notable example, is Jabber XML-RPC. One can write a Jabber client that automates a remote Component (DCOM, Corba, EJB). If we use Jabber, we have complete control over the format of the data we transmit, as long as it's XML. That's why the call it _eXtensbile_ Messaging and Presence Protocol (XMPP). Of course, if we want a server to step in and do anything, we need to write a custom Jabber component. If we stay client-heavy, we never need to do this. As for a JEP, no one implements a JEP until it has gone through at least a year of peer review, except for the original authors. The reason I'd like to write one, is its the expected method of communicating with the Jabber community our intentions, so that they can peer review our work. The JEP authors usually are the only ones implementing the JEP at first. Then, once the JEP has been accepted, others may jump on the bandwagon and implement a Jabber client that supports whatever the JEP adds. But, they don't have to. Just like Convey never has to have a buddy list or post presence information. Another thing I want to point out, is that Jabber is NOT an IM system. I have been referring to Jabber as an IM system in err. IM is just the most common use it's put to. XML-RPC is justification for the validity that Jabber is not only an IM system. Here's where I stand on the topic, if we a) decide to go Jabber, and b) want the community to peer review us, then we write a JEP to facilitate the peer review. OTOH, if we don't go Jabber, we must justify to ourselves the value of this choice. Currently, I do not see the justification since the design of Jabber was to provide a framework for doing what we're trying to do. To aid in this decision, we must define the requirements of the system we want to design and implement. If Jabber falls short of these requirements, then we do not use it. Of course, I'm sure this won't be that simple. Jabber may meet all requirements but a few. If that's the case, then we can consider a server extension. (BTW, we can choose to use the Jabber server and protocol, and decide we don't care about interoperability with other Jabbers users and IM systems. In this case, we'd just be using Jabber as a springboard into our own custom implementation.) Andy <snip> |
|
From: Scott L. <sco...@ho...> - 2003-08-17 23:42:44
|
Hello, I think the JEP title "Collaborative XML Document Editing" is a telling one. It is good because it captures a lot of what we have been discussing. The unit of focus is an "XML document", and this implies a measure of extenibility to derivative specs such as SVG, MathML, etc. Also, "editing" is the core of the problem which subsumes questions about concurrency, canvas resolution schemes, and, inevitably, about essential architectural details (i.e. the location of the document). Furthermore, the title emphasizes the primay goal of achieving a way to "collaborate". This may be accomplished by using an IM protocol such as Jabber. (Let me be straightforward, and pardon me if I sound too blunt.) However, I see great potential in Convey which transcends the limitations of Instant Messaging, the primary one being that a central server is necessary. Writing a client for Jabber may be necessary for a wide variety of good reasons. However, I think that to have the design of Convey influenced and constrained by JSF and its guidelines may run counter to the fundamental reasons of why I am excited about this project. Its potential greatly appeals to me. What is its potential? Its potential to transact in XML rather than a specific grammar of XML (ie. SVG), as we discussed, increases its applicability. There is another potential which I want to highlight. I think there is a way to design Convey so that it is compatible with IM protocols like Jabber and also decentralized P-2-P protocols (which currently may have aspects that still problematic, but its promise is captivating). Convey has great potential to be adaptable in this way -- of not being limited to or dependent on a specific kind of collaborative technology. A Convey which works with Jabber may use only its basic requirements of sending, receiving, login, etc; no extensions would be necessary. It is client-heavy because it uses the server only to relay messages. All other tasks are its responsibility. But writing a JEP may be worthwhile for many reasons. However, in my thinking, the persuasive force of Convey resides outside of the Jabber world. Jabber, like expat and wxWindows, is an enabling component for Convey. The core of Convey, also in my thinking, and perhaps in yours too, is how it addresses concurrency issues to allow for collaborative editing of XML documents. I would like to hear your opinion on the friendly comments above. Scott >From: "Andy Ames" <ag...@sb...> >Reply-To: con...@li... >To: <con...@li...> >Subject: [convey-developers] JEP - Collaborative XML Document Editing >Date: Fri, 15 Aug 2003 12:18:21 -0700 > >Hey, guys. > >This is partly a summary of a discussion Ed and I had and partly a >collection of my own thoughts on the subject. > >I propose that we write a Jabber Enhacement Proposal (JEP), with the >assistance of the Jabber Software Foundation (JSF), titled "Collaborative >XML Document Editing." Following is a collection of information that might >be relevant in getting started with a set of requirements for the protocol. > >1) Service Discovery > >Ed and I discovered that collaboration support was intended in the Jabber >spec. There is a JEP called Service Discovery (JEP 0030), which is intended >to supersede Jabber Browsing (JEP 0011) and Agent Information (JEP 0094). > >Jabber Browsing and Agent Information describe a request/response method of >querying a Jabber server's supported capabilities, a conference room's >paramaters, and even the participants of a conference room. > >Service Discovery is a much more flexible implementation of this querying >process. To give you an idea of what the Service Discovery XML looks like, >the following is an example of querying a JID (server) for supported >features and other information. > >SEND: <iq type='get' > from='ro...@mo.../orchard' > to='plays.shakespeare.lit' > id='info1'> > <query xmlns='http://jabber.org/protocol/disco#info'/> > </iq> > >RECV: <iq type='result' > from='plays.shakespeare.lit' > to='ro...@mo.../orchard' > id='info1'> > <query xmlns='http://jabber.org/protocol/disco#info'> > <identity category='conference' > type='text' > name='Play-Specific Chatrooms'/> > <identity category='directory' > type='room' > name='Play-Specific Chatrooms'/> > <feature var='gc-1.0'/> > <feature var='http://jabber.org/protocol/muc'/> > <feature var='jabber:iq:register'/> > <feature var='jabber:iq:search'/> > <feature var='jabber:iq:time'/> > <feature var='jabber:iq:version'/> > </query> > </iq> > >If you go to the following link, you'll see tables with the existing >registered types that may be advertised by JIDs and their nodes. The page >is >titled "Parameters for Service Discovery." > >http://www.jabber.org/registrar/disco.html > >The thing to notice is that there are registered Collaboration categories >(editor and whiteboard) for multi-user collaboration. This category is >separate from the Conference categories (irc and text). > >2) Multi-User Text Editing (JEP 0058) > >http://www.jabber.org/jeps/jep-0058.html > >This JEP is a very simple protocol for multiple users editing a plain-text >document using the diff format. The actual text documents are stored on the >server. A Jabber client may query the server for editable text documents >using a protocol like Service Discovery, but it's not. The server responds >with a list of editable texts. > >The Jabber client may then choose to subscribe to one of them. This means >all diffs sent by other parties will be forwarded to our Jabber client. The >client may subscribe with read-only or read-write access. The Jabber client >may then be used to make edits of the text document. All other subscribed >users will immediately see the results. > >This JEP is experimental and is NOT a recommendation. The first problem >that >I see with it is that is uses none of the standard JEPs (Service Discovery >or Jabber Browsing) for querying editable texts. > >3) Whiteboarding JIG > >http://www.jabber.org/jeps/jep-0010.html > >JEPs are not only for Jabber protocol enhancements. They're also used for >informational purposes or to inspire the JSF to take some action. That's >what the "Whiteboarding JIG" is for. It is a call to create a Jabber >Interest Group (JIG) to develop a Whiteboarding protocol enhancement. It >outlines some basic requirements for the protocol and gives some direction >to the JIG. > >This JEP cannot be found in the list of JEPs because its status has been >changed to obsolete. I discuss this in the next section. > >4) Jabber Interest Groups (JIGs) > >The status of the "Whiteboarding JIG" has been change to Obsolete because >JIGs have produced very little in the several years since they were >created. >See "Streamlining the JIGs" (JEP 0019) for a description of the problem and >explanation of why the JIGs have been disbanded. > >http://www.jabber.org/jeps/jep-0019.html > >To summarize, the Jabber community wasn't large enough to warrant the >creation of 10 separate JIGs. Nearly all of the JEPs that have been >produced >since the advent of JIGs has not been by the JIGs. The JEPs have been >created by individuals or small ad-hoc groups from outside the >organization. > >They did leave in tact the Standards JIG because that is where most of the >discussion of JEPs that came from outside the JSF occurred. It is >incredibly >active. I suggest we all join the mailing list. > >http://mailman.jabber.org/listinfo/standards-jig/ > >5) Jabber Enhancement Proposals (JEPs) > >The basic idea is that small, outside groups will draft JEPs, then discuss >them on that mailing list. Then, the group will continue to rewrite the JEP >based on the feedback. This process continues until there is a certain >amount of acceptance of the JEP by the Standards JIG community. > >At that point, the JEP is submitted for formal review by the Jabber >Council. >This is where the JEP is voted on for acceptance. The following link shows >the results of this year's votes. > >http://www.jabber.org/council/tallies_02.html > >This link is a more formal description of the JEP process: > >http://www.jabber.org/jeps/submit.php > >I might add that many JEPs never make it to the Jabber Council for one >reason or another. Also, many JEPs start out as proprietary extensions to >the Jabber protocol using <x/> child elements of <message/> elements. > >It is common to have an experimental server implementation in use during >the >drafting of the JEP. > >In other words, we do not have to let the JEP process interfere with us >creating Convey. > >6) Jabberzilla > >http://jabberzilla.mozdev.org/ > >Jabberzilla is a web-based Jabber client that was built directly into the >Mozilla sidebar. Mozilla is the successor to Netscape. > >Whiteboarding functionality was just added to Jabberzilla almost a year >ago. >Check out the screenshots for December 2001, January 2002, and March 2002: > >http://jabberzilla.mozdev.org/screenshots/ > >Mozilla has an SVG rendering library built directly into it. So, all you >have to do is provide an SVG DOM or file, and Mozilla can render it to a >window. Jabberzilla uses this feature to draw the SVG. > >The problem is that the Mozilla team removed the SVG from recent builds, so >the Jabberzilla whiteboard only works with older builds of Mozilla. > >The whiteboard is strictly a whiteboard. Meaning, when a user draws >something, it stays. No one can edit what was drawn, not even the artist. >You can, of course, clear the whiteboard and use an eraser. This type of >whiteboarding is much easier to implement that collaborative document >editing because every drawn graphic is simply appended to the end of the >SVG >DOM tree. > >By looking at the SVG sent by Jabberzilla, it seems that he hasn't solved >the concurrency problem. So, like Convey Java, graphic messages may appear >in different orders for different users. > >7) Coccinella > >http://hem.fyristorg.com/matben/ > >This is another Jabber-based whiteboard. This one is even more limited than >Jabberzilla. All you can do is draw the SVG content, then send the document >all-at-once to a recipient. Actually, it doesn't even use SVG. > >The weird thing is, it has MP3 and Quicktime support via a plugin >architecture. > >There is no concurrency issue with this client because of its all-at-once >nature. > >8) SVG Whiteboard > >http://oid.jabber.org/?oid=1025 > >This guy was attempting to solve the same problems as us. However, the link >to the project site is broken. The link above is imply a news announcement >he posted of a 0.1 release to the Jabber community. > >However, if you go to the domain where the broken link points at, you'll >find Mobile SVG and PDF document viewing: > >http://bitflash.com/ > >9) Whiteboarding Proposal > >http://www.protocol7.com/jabber/ > >This is the web page of the guy who originally submitted the Whiteboarding >JIG (JEP 0010). He has some example Jabber XML for the whiteboard and a >DTD. >It uses a subset of the SVG spec. > >It doesn't look like he has an implementation, though. > >Anyway, feel free to comment on any or all of these topics. If you both are >in agreement regarding a Collaborative XML Document Editing JEP, then the >next step is to focus in on requirements. > >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-15 19:35:01
|
Hey, guys.
This is partly a summary of a discussion Ed and I had and partly a
collection of my own thoughts on the subject.
I propose that we write a Jabber Enhacement Proposal (JEP), with the
assistance of the Jabber Software Foundation (JSF), titled "Collaborative
XML Document Editing." Following is a collection of information that might
be relevant in getting started with a set of requirements for the protocol.
1) Service Discovery
Ed and I discovered that collaboration support was intended in the Jabber
spec. There is a JEP called Service Discovery (JEP 0030), which is intended
to supersede Jabber Browsing (JEP 0011) and Agent Information (JEP 0094).
Jabber Browsing and Agent Information describe a request/response method of
querying a Jabber server's supported capabilities, a conference room's
paramaters, and even the participants of a conference room.
Service Discovery is a much more flexible implementation of this querying
process. To give you an idea of what the Service Discovery XML looks like,
the following is an example of querying a JID (server) for supported
features and other information.
SEND: <iq type='get'
from='ro...@mo.../orchard'
to='plays.shakespeare.lit'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
RECV: <iq type='result'
from='plays.shakespeare.lit'
to='ro...@mo.../orchard'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='conference'
type='text'
name='Play-Specific Chatrooms'/>
<identity category='directory'
type='room'
name='Play-Specific Chatrooms'/>
<feature var='gc-1.0'/>
<feature var='http://jabber.org/protocol/muc'/>
<feature var='jabber:iq:register'/>
<feature var='jabber:iq:search'/>
<feature var='jabber:iq:time'/>
<feature var='jabber:iq:version'/>
</query>
</iq>
If you go to the following link, you'll see tables with the existing
registered types that may be advertised by JIDs and their nodes. The page is
titled "Parameters for Service Discovery."
http://www.jabber.org/registrar/disco.html
The thing to notice is that there are registered Collaboration categories
(editor and whiteboard) for multi-user collaboration. This category is
separate from the Conference categories (irc and text).
2) Multi-User Text Editing (JEP 0058)
http://www.jabber.org/jeps/jep-0058.html
This JEP is a very simple protocol for multiple users editing a plain-text
document using the diff format. The actual text documents are stored on the
server. A Jabber client may query the server for editable text documents
using a protocol like Service Discovery, but it's not. The server responds
with a list of editable texts.
The Jabber client may then choose to subscribe to one of them. This means
all diffs sent by other parties will be forwarded to our Jabber client. The
client may subscribe with read-only or read-write access. The Jabber client
may then be used to make edits of the text document. All other subscribed
users will immediately see the results.
This JEP is experimental and is NOT a recommendation. The first problem that
I see with it is that is uses none of the standard JEPs (Service Discovery
or Jabber Browsing) for querying editable texts.
3) Whiteboarding JIG
http://www.jabber.org/jeps/jep-0010.html
JEPs are not only for Jabber protocol enhancements. They're also used for
informational purposes or to inspire the JSF to take some action. That's
what the "Whiteboarding JIG" is for. It is a call to create a Jabber
Interest Group (JIG) to develop a Whiteboarding protocol enhancement. It
outlines some basic requirements for the protocol and gives some direction
to the JIG.
This JEP cannot be found in the list of JEPs because its status has been
changed to obsolete. I discuss this in the next section.
4) Jabber Interest Groups (JIGs)
The status of the "Whiteboarding JIG" has been change to Obsolete because
JIGs have produced very little in the several years since they were created.
See "Streamlining the JIGs" (JEP 0019) for a description of the problem and
explanation of why the JIGs have been disbanded.
http://www.jabber.org/jeps/jep-0019.html
To summarize, the Jabber community wasn't large enough to warrant the
creation of 10 separate JIGs. Nearly all of the JEPs that have been produced
since the advent of JIGs has not been by the JIGs. The JEPs have been
created by individuals or small ad-hoc groups from outside the organization.
They did leave in tact the Standards JIG because that is where most of the
discussion of JEPs that came from outside the JSF occurred. It is incredibly
active. I suggest we all join the mailing list.
http://mailman.jabber.org/listinfo/standards-jig/
5) Jabber Enhancement Proposals (JEPs)
The basic idea is that small, outside groups will draft JEPs, then discuss
them on that mailing list. Then, the group will continue to rewrite the JEP
based on the feedback. This process continues until there is a certain
amount of acceptance of the JEP by the Standards JIG community.
At that point, the JEP is submitted for formal review by the Jabber Council.
This is where the JEP is voted on for acceptance. The following link shows
the results of this year's votes.
http://www.jabber.org/council/tallies_02.html
This link is a more formal description of the JEP process:
http://www.jabber.org/jeps/submit.php
I might add that many JEPs never make it to the Jabber Council for one
reason or another. Also, many JEPs start out as proprietary extensions to
the Jabber protocol using <x/> child elements of <message/> elements.
It is common to have an experimental server implementation in use during the
drafting of the JEP.
In other words, we do not have to let the JEP process interfere with us
creating Convey.
6) Jabberzilla
http://jabberzilla.mozdev.org/
Jabberzilla is a web-based Jabber client that was built directly into the
Mozilla sidebar. Mozilla is the successor to Netscape.
Whiteboarding functionality was just added to Jabberzilla almost a year ago.
Check out the screenshots for December 2001, January 2002, and March 2002:
http://jabberzilla.mozdev.org/screenshots/
Mozilla has an SVG rendering library built directly into it. So, all you
have to do is provide an SVG DOM or file, and Mozilla can render it to a
window. Jabberzilla uses this feature to draw the SVG.
The problem is that the Mozilla team removed the SVG from recent builds, so
the Jabberzilla whiteboard only works with older builds of Mozilla.
The whiteboard is strictly a whiteboard. Meaning, when a user draws
something, it stays. No one can edit what was drawn, not even the artist.
You can, of course, clear the whiteboard and use an eraser. This type of
whiteboarding is much easier to implement that collaborative document
editing because every drawn graphic is simply appended to the end of the SVG
DOM tree.
By looking at the SVG sent by Jabberzilla, it seems that he hasn't solved
the concurrency problem. So, like Convey Java, graphic messages may appear
in different orders for different users.
7) Coccinella
http://hem.fyristorg.com/matben/
This is another Jabber-based whiteboard. This one is even more limited than
Jabberzilla. All you can do is draw the SVG content, then send the document
all-at-once to a recipient. Actually, it doesn't even use SVG.
The weird thing is, it has MP3 and Quicktime support via a plugin
architecture.
There is no concurrency issue with this client because of its all-at-once
nature.
8) SVG Whiteboard
http://oid.jabber.org/?oid=1025
This guy was attempting to solve the same problems as us. However, the link
to the project site is broken. The link above is imply a news announcement
he posted of a 0.1 release to the Jabber community.
However, if you go to the domain where the broken link points at, you'll
find Mobile SVG and PDF document viewing:
http://bitflash.com/
9) Whiteboarding Proposal
http://www.protocol7.com/jabber/
This is the web page of the guy who originally submitted the Whiteboarding
JIG (JEP 0010). He has some example Jabber XML for the whiteboard and a DTD.
It uses a subset of the SVG spec.
It doesn't look like he has an implementation, though.
Anyway, feel free to comment on any or all of these topics. If you both are
in agreement regarding a Collaborative XML Document Editing JEP, then the
next step is to focus in on requirements.
Andy
|
|
From: Scott L. <sco...@ho...> - 2003-08-12 00:10:48
|
Andy, Thanks for all your thoughts about process -- which I think is important and deserves attention. Scott >From: "Andy Ames" <ag...@sb...> >Reply-To: con...@li... >To: <con...@li...> >Subject: [convey-developers] sourceforge tasks, bugs, feature requests >Date: Sat, 9 Aug 2003 13:37:48 -0700 > >I reorganized the sourceforge project. > >We now have tasks, but only under the wxXml subproject. Items on the task >list are items that will be implemented. Also, in the wxxml source docs, I >referenced the task # from the appropriate class or method using the @todo >tag. See any of the wxXml headers for an example. > >The Bug and Feature Request trackers now have the following Categories: > >Convey Java >wxConvey >wxConvey : wxXml >wxConvey : wxJab > >They're self-explanatory. > >So, Ed, you may have gotten a flood of messages regarding tracker item >changes. That's what this is all about. I have items with the "wxConvey : >wxXml" Category automatically getting assigned to you, Ed. > >They way I've been conceptualizing this whole process is like this: > >1) Tasks > >The subproject owner is responsible for creating and managing tasks in >their >subproject, as well as assigning tasks (assuming of course the person they >assign a task to agrees). Anyone can add comments to a task to give their >feedback or insight. > >I imagine, though, that the discussions will occur on this mailing list, >and >then the conclusions get pasted into the task by the subproject owner. > >Each Task will also be referenced from the source code doc "@todo" items. >This may not be necessary, but it certainly helps remind us of upcoming >changes when we're browsing the code. > >2) Bugs > >Anyone can submit bug reports on a subproject. The subproject owner is >ultimately the person who determines if the bug really is a bug, and if and >when it will be fixed. Again, the subproject owner can leverage any other >developer's time and resources to accomplish this. > >Each bug that is determined to be valid by the subproject owner will also >be >referenced from the revelant source docs using the "@bug" tag. This can be >done whether or not the subproject owner intends to fix the bug. > >3) Feature Requests > >Anyone can submit these. The subproject owner manages these items through >their lifecycle like they do with bugs. > >Feature Requests would be the place where developers make suggestions to >the >subproject owner regarding their subproject. > >Feature Requests, once accepted by the subproject owner, are turned into >task items. > >4) Developers Mailing List > >This, of course, is where most of the discussions begin. Also, many >dicscussions from here will be filtered down into a task, bug, or feature >request, as necessary. > >5) Conclusion > >There's a hierarchy of content flow: > >--- Mailing List > | > --- Bug > | | > | ---Task > | > --- Feature Request > | > ---Task > >Content flows from the root to a child. At any stage, the content may be >rejected as being inconsequential. Before entering the Task node, the issue >gets the subproject owner's full approval. > >Of course, this is somewhat simplified, since content can be generated >offline (verbal discussions) or by non-team members submitting items. BTW, >the only non-team members likely to submit something are other developers >using our product/APIs in some way. Convey client users, OTOH, are likely >to >want something a little simpler. Ed's idea was to have a bug report dialog >box in Convey. This could send a message (via Jabber) to some place >(chatroom?) where we pick it up and filter it down or content flow >hierarchy. > >Anyway, sound good? I think this works for now. When we start bringing on >more developers, we can get more specific about this process. > >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: Ed B. <edb...@ca...> - 2003-08-10 19:26:05
|
Thanks, Andy. Comments below... On Sat, 9 Aug 2003 13:37:48 -0700 "Andy Ames" <ag...@sb...> wrote: > I reorganized the sourceforge project. > > We now have tasks, but only under the wxXml subproject. > Items on the task > list are items that will be implemented. Also, in the > wxxml source docs, I > referenced the task # from the appropriate class or > method using the @todo > tag. See any of the wxXml headers for an example. > > The Bug and Feature Request trackers now have the > following Categories: > > Convey Java > wxConvey > wxConvey : wxXml > wxConvey : wxJab > > They're self-explanatory. Yes they are. Nice organizing. > > They way I've been conceptualizing this whole process is > like this:> > 1) Tasks > > The subproject owner is responsible for creating and > managing tasks in their > subproject, as well as assigning tasks (assuming of > course the person they > assign a task to agrees). Anyone can add comments to a > task to give their > feedback or insight. > > I imagine, though, that the discussions will occur on > this mailing list, and > then the conclusions get pasted into the task by the > subproject owner. > > Each Task will also be referenced from the source code > doc "@todo" items. > This may not be necessary, but it certainly helps remind > us of upcoming > changes when we're browsing the code. > > 2) Bugs > > Anyone can submit bug reports on a subproject. The > subproject owner is > ultimately the person who determines if the bug really is > a bug, and if and > when it will be fixed. Again, the subproject owner can > leverage any other > developer's time and resources to accomplish this. > > Each bug that is determined to be valid by the subproject > owner will also be > referenced from the revelant source docs using the "@bug" > tag. This can be > done whether or not the subproject owner intends to fix > the bug. > > 3) Feature Requests > > Anyone can submit these. The subproject owner manages > these items through > their lifecycle like they do with bugs. > > Feature Requests would be the place where developers make > suggestions to the > subproject owner regarding their subproject. > > Feature Requests, once accepted by the subproject owner, > are turned into > task items. > > 4) Developers Mailing List > > This, of course, is where most of the discussions begin. > Also, many > dicscussions from here will be filtered down into a task, > bug, or feature > request, as necessary. > > 5) Conclusion > > There's a hierarchy of content flow: > > --- Mailing List > | > --- Bug > | | > | ---Task > | > --- Feature Request > | > ---Task > > Content flows from the root to a child. At any stage, the > content may be > rejected as being inconsequential. Before entering the > Task node, the issue > gets the subproject owner's full approval. > > Of course, this is somewhat simplified, since content can > be generated > offline (verbal discussions) or by non-team members > submitting items. BTW, > the only non-team members likely to submit something are > other developers > using our product/APIs in some way. Convey client users, > OTOH, are likely to > want something a little simpler. Ed's idea was to have a > bug report dialog > box in Convey. This could send a message (via Jabber) to > some place > (chatroom?) where we pick it up and filter it down or > content flow > hierarchy. > Yes, I haven't finished this way of bug reporting and am wondering if this would be too much to add at this late date. > Anyway, sound good? I think this works for now. When we > start bringing on > more developers, we can get more specific about this > process. It sounds fine. We don't really have that many developers so the process probably only needs clarifying on a as-needed basis. When we find ourselves spending alot of time clarifying the process, then we should sit down and spend a bit more time on formalizing the process. Thanks, Andy. |
|
From: Andy A. <ag...@sb...> - 2003-08-09 20:38:03
|
I reorganized the sourceforge project.
We now have tasks, but only under the wxXml subproject. Items on the task
list are items that will be implemented. Also, in the wxxml source docs, I
referenced the task # from the appropriate class or method using the @todo
tag. See any of the wxXml headers for an example.
The Bug and Feature Request trackers now have the following Categories:
Convey Java
wxConvey
wxConvey : wxXml
wxConvey : wxJab
They're self-explanatory.
So, Ed, you may have gotten a flood of messages regarding tracker item
changes. That's what this is all about. I have items with the "wxConvey :
wxXml" Category automatically getting assigned to you, Ed.
They way I've been conceptualizing this whole process is like this:
1) Tasks
The subproject owner is responsible for creating and managing tasks in their
subproject, as well as assigning tasks (assuming of course the person they
assign a task to agrees). Anyone can add comments to a task to give their
feedback or insight.
I imagine, though, that the discussions will occur on this mailing list, and
then the conclusions get pasted into the task by the subproject owner.
Each Task will also be referenced from the source code doc "@todo" items.
This may not be necessary, but it certainly helps remind us of upcoming
changes when we're browsing the code.
2) Bugs
Anyone can submit bug reports on a subproject. The subproject owner is
ultimately the person who determines if the bug really is a bug, and if and
when it will be fixed. Again, the subproject owner can leverage any other
developer's time and resources to accomplish this.
Each bug that is determined to be valid by the subproject owner will also be
referenced from the revelant source docs using the "@bug" tag. This can be
done whether or not the subproject owner intends to fix the bug.
3) Feature Requests
Anyone can submit these. The subproject owner manages these items through
their lifecycle like they do with bugs.
Feature Requests would be the place where developers make suggestions to the
subproject owner regarding their subproject.
Feature Requests, once accepted by the subproject owner, are turned into
task items.
4) Developers Mailing List
This, of course, is where most of the discussions begin. Also, many
dicscussions from here will be filtered down into a task, bug, or feature
request, as necessary.
5) Conclusion
There's a hierarchy of content flow:
--- Mailing List
|
--- Bug
| |
| ---Task
|
--- Feature Request
|
---Task
Content flows from the root to a child. At any stage, the content may be
rejected as being inconsequential. Before entering the Task node, the issue
gets the subproject owner's full approval.
Of course, this is somewhat simplified, since content can be generated
offline (verbal discussions) or by non-team members submitting items. BTW,
the only non-team members likely to submit something are other developers
using our product/APIs in some way. Convey client users, OTOH, are likely to
want something a little simpler. Ed's idea was to have a bug report dialog
box in Convey. This could send a message (via Jabber) to some place
(chatroom?) where we pick it up and filter it down or content flow
hierarchy.
Anyway, sound good? I think this works for now. When we start bringing on
more developers, we can get more specific about this process.
Andy
|
|
From: Andy A. <ag...@sb...> - 2003-08-09 02:29:19
|
Scott, Do you have a sourceforge account I can use to add you to Convey? Can you create one and send me the username? Andy |
|
From: Andy A. <ag...@sb...> - 2003-08-09 02:18:13
|
Ed, The wxxml mod is officially yours. Check out of CVS: cvs -d:ext:use...@cv...:/cvsroot/convey co wxxml (I find it easiest to do this check out right next to all my other Convey repository checkouts.) There's a README and BUILD file at the root that will help you navigate the project. Currently, there's only a build setup for MSVC. There's no Makefile or autoconf setup. We need to do this to make it easier for anyone to build it. Until then, we can setup a CodeWarrior or Project Builder project for building the library. Then, commit these projects to CVS. That way, you'll be able to do stuff with the library now. Andy |
|
From: Andy A. <ag...@sb...> - 2003-08-08 19:25:25
|
Okay, wxxml to Ed; wxjab to Scott. Today, I'm going to do one last round of documenting the wxxml mod. I'll include known issues, bugs and todo items. I'll do the same with wxjab over the weekend. Scott, I'll make sure you have write access to the repository. Andy -----Original Message----- From: con...@li... [mailto:con...@li...]On Behalf Of Ed Braunhut Sent: Friday, August 08, 2003 11:12 AM To: con...@li... Subject: Re: [convey-developers] wxjab module via wxxml I would like to be responsible for the wxxml module. Ed On Wednesday, August 6, 2003, at 07:45 PM, Andy Ames wrote: Okay, you both are interested in taking a module. Do you guys want to choose who gets wxxml and who gets wxjab. I'll be ready to turn over wxjab by the end of this weekend. Andy -----Original Message----- From: con...@li... [mailto:con...@li...]On Behalf Of Scott Luan Sent: Monday, August 04, 2003 10:53 PM To: con...@li... Subject: Re: [convey-developers] wxjab module via wxxml 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 ------------------------------------------------------- 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 |
1 message has been excluded from this view by a project administrator.
