ramp-devl Mailing List for Rapid Asynchronous Messaging Protocol
Brought to you by:
zer0wing
Menu
▾
▴
ramp-devl — List to be used only by developers of Ramp
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(12) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Matt P. <pa...@cu...> - 2005-03-29 22:34:48
|
I must have described the problem badly. We don't have to deal with multiple sockets and switching context. That part is taken care of, what I have to deal with is that to process the incoming information, I need to get all of the blocks of data using the NIO chunk analogy. Then I assemble them into a stream and reuse all the old code that worked on the stream analogy from before. I just don't like that part. It seems like I'm creating and destroying a bunch of things, and I keep thinking there is a more graceful way to get the generated ramp code to take apart the chunks properly. Perhaps I'm wrong, maybe I have to get all the data together before I process it. But, even if I do that I think there must be a way to get that together much better than the way I'm doing it now. If none of that makes sense, think about it this way. Sockets arn't the problem here, nor is context switching. Its how to process the chunks of data I'm getting in the fastest way possible. I have a working solution now, it just feels clunky. -M Ben wrote: >Ok, I'm confused. It sounds like your problem is simply that with NIO you >might not get all the bytes you wanted before you change contexts and >start getting data from another socket. How is that different than any >normal socket operation? > >On Tue, 29 Mar 2005, Matt Paulin wrote: > > > >>Its not so much the design, >> >>more of how to marry the previous concept that Ramp was built around, to >>the new concept. I found a way that works, but it feels hacky and I >>keep thinking there is a better way. Ignoring the java aspect the >>problem lays out like this. >> >>Previously I had a stream of bytes and a hard coded structure for >>turning them back into a data structure. You grab the first byte, that >>tells you the message, then you construct the necessary objects and >>hydrate them with the bytes. Its assumed that each message has a >>determinable number of bytes and that can't change. >> >>The problem now is with this block. I have a block of bytes and if I >>take my block of bytes and start to hydrate the data structure, I could >>very well run out of bytes to use. So now I'm stuck. I had thought >>about getting an exact size for each message and then checking to make >>sure I have enough bytes before hydration, if not, then I grab more >>bytes. The problem here is with strings and UTF-8. I'm still searching >>for a way to tell how much of those bytes are to be transformed into the >>appropriate number of characters. I'm sure this is possible, and with >>some generated size methods I could figure out how many bytes each >>message is suppose to have. This is nice also because its very similar >>to the C version. >> >>I had also thought about making the buffer giant, but this just >>postpones the problem till something really large shows up. >> >>Other ideas? >> >>One thing is for sure, that some good unit test need to be drawn up to >>put this together properly. >> -M >> >> >>Ben wrote: >> >> >> >>>I'm unfamiliar with java in general and NIO in particular, but I have >>>worked with asynch i/o before, and it sounds like that's what you're >>>talking about. I can offer general suggestions of how to deal with that. >>> >>>On Tue, 29 Mar 2005, Matt Paulin wrote: >>> >>> >>> >>> >>> >>>>Wouldn't that make a superior title for a O'Relly book? I can image it >>>>would be equally stocked with good excuses as information. Just think >>>>you could tell your boss. Sure the server died, but did you see the >>>>drama and could you feel the pain of its death. >>>> >>>>Thats not really here nor there, but in working with NIO I have been >>>>thinking about this a bit. Seems there are many ways to screw it up, >>>>and only lots of testing will fix it. >>>> >>>>So I have been converting from the old IO with data input and output >>>>stream to the NIO stuff. Pretty interesting really, gives you tons of >>>>control. For instance, now I can totally control what character set is >>>>being sent, for instance, we are using UTF-8. THat was your only choice >>>>with regular IO operations. Now I can do all sorts of stuff. Not >>>>really very useful though, considering UTF-8 is one of the best. >>>> >>>>Now if anyone is interested in how to work with NIO, I could certainly >>>>use the review and ideas. I'm thinking it will need a bit of unit >>>>testing as well. So far I have seen a place or two where a thread pool >>>>would be handy for spinning off messages that just arrived. Also NIO >>>>uses this block transfer analogy instead of the stream analogy. It >>>>makes more sense, probibly wraps the whole thing into a packet to send >>>>it. But, its really tricky to unmarshal a block expecially if you only >>>>got half of the peices in your limited size buffer. My work around >>>>right now has been to pump the bytes out of the block into a stream and >>>>then just use the stream. That doesn't seem to be the best way, but is >>>>appears to be working. >>>> >>>>Anyway, its pretty cool stuff, but will take some innovation and ideas >>>>to make it really effective. Marcus if you are any of your crew are >>>>interested I could use the review and discussion. Until then I think I >>>>will just plan to fail gracefully. >>>>-M >>>> >>>> >>>> >>>>------------------------------------------------------- >>>>SF email is sponsored by - The IT Product Guide >>>>Read honest & candid reviews on hundreds of IT Products from real users. >>>>Discover which products truly live up to the hype. Start reading now. >>>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>>>_______________________________________________ >>>>Ramp-devl mailing list >>>>Ram...@li... >>>>https://lists.sourceforge.net/lists/listinfo/ramp-devl >>>> >>>> >>>> >>>> >>>> >>> >>> >>>------------------------------------------------------- >>>SF email is sponsored by - The IT Product Guide >>>Read honest & candid reviews on hundreds of IT Products from real users. >>>Discover which products truly live up to the hype. Start reading now. >>>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>>_______________________________________________ >>>Ramp-devl mailing list >>>Ram...@li... >>>https://lists.sourceforge.net/lists/listinfo/ramp-devl >>> >>> >>> >>> >> >>------------------------------------------------------- >>SF email is sponsored by - The IT Product Guide >>Read honest & candid reviews on hundreds of IT Products from real users. >>Discover which products truly live up to the hype. Start reading now. >>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>_______________________________________________ >>Ramp-devl mailing list >>Ram...@li... >>https://lists.sourceforge.net/lists/listinfo/ramp-devl >> >> >> > > > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >_______________________________________________ >Ramp-devl mailing list >Ram...@li... >https://lists.sourceforge.net/lists/listinfo/ramp-devl > > |
|
From: Ben <be...@si...> - 2005-03-29 21:51:55
|
Ok, I'm confused. It sounds like your problem is simply that with NIO you might not get all the bytes you wanted before you change contexts and start getting data from another socket. How is that different than any normal socket operation? On Tue, 29 Mar 2005, Matt Paulin wrote: > Its not so much the design, > > more of how to marry the previous concept that Ramp was built around, to > the new concept. I found a way that works, but it feels hacky and I > keep thinking there is a better way. Ignoring the java aspect the > problem lays out like this. > > Previously I had a stream of bytes and a hard coded structure for > turning them back into a data structure. You grab the first byte, that > tells you the message, then you construct the necessary objects and > hydrate them with the bytes. Its assumed that each message has a > determinable number of bytes and that can't change. > > The problem now is with this block. I have a block of bytes and if I > take my block of bytes and start to hydrate the data structure, I could > very well run out of bytes to use. So now I'm stuck. I had thought > about getting an exact size for each message and then checking to make > sure I have enough bytes before hydration, if not, then I grab more > bytes. The problem here is with strings and UTF-8. I'm still searching > for a way to tell how much of those bytes are to be transformed into the > appropriate number of characters. I'm sure this is possible, and with > some generated size methods I could figure out how many bytes each > message is suppose to have. This is nice also because its very similar > to the C version. > > I had also thought about making the buffer giant, but this just > postpones the problem till something really large shows up. > > Other ideas? > > One thing is for sure, that some good unit test need to be drawn up to > put this together properly. > -M > > > Ben wrote: > > >I'm unfamiliar with java in general and NIO in particular, but I have > >worked with asynch i/o before, and it sounds like that's what you're > >talking about. I can offer general suggestions of how to deal with that. > > > >On Tue, 29 Mar 2005, Matt Paulin wrote: > > > > > > > >>Wouldn't that make a superior title for a O'Relly book? I can image it > >>would be equally stocked with good excuses as information. Just think > >>you could tell your boss. Sure the server died, but did you see the > >>drama and could you feel the pain of its death. > >> > >>Thats not really here nor there, but in working with NIO I have been > >>thinking about this a bit. Seems there are many ways to screw it up, > >>and only lots of testing will fix it. > >> > >>So I have been converting from the old IO with data input and output > >>stream to the NIO stuff. Pretty interesting really, gives you tons of > >>control. For instance, now I can totally control what character set is > >>being sent, for instance, we are using UTF-8. THat was your only choice > >>with regular IO operations. Now I can do all sorts of stuff. Not > >>really very useful though, considering UTF-8 is one of the best. > >> > >>Now if anyone is interested in how to work with NIO, I could certainly > >>use the review and ideas. I'm thinking it will need a bit of unit > >>testing as well. So far I have seen a place or two where a thread pool > >>would be handy for spinning off messages that just arrived. Also NIO > >>uses this block transfer analogy instead of the stream analogy. It > >>makes more sense, probibly wraps the whole thing into a packet to send > >>it. But, its really tricky to unmarshal a block expecially if you only > >>got half of the peices in your limited size buffer. My work around > >>right now has been to pump the bytes out of the block into a stream and > >>then just use the stream. That doesn't seem to be the best way, but is > >>appears to be working. > >> > >>Anyway, its pretty cool stuff, but will take some innovation and ideas > >>to make it really effective. Marcus if you are any of your crew are > >>interested I could use the review and discussion. Until then I think I > >>will just plan to fail gracefully. > >> -M > >> > >> > >> > >>------------------------------------------------------- > >>SF email is sponsored by - The IT Product Guide > >>Read honest & candid reviews on hundreds of IT Products from real users. > >>Discover which products truly live up to the hype. Start reading now. > >>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >>_______________________________________________ > >>Ramp-devl mailing list > >>Ram...@li... > >>https://lists.sourceforge.net/lists/listinfo/ramp-devl > >> > >> > >> > > > > > > > > > >------------------------------------------------------- > >SF email is sponsored by - The IT Product Guide > >Read honest & candid reviews on hundreds of IT Products from real users. > >Discover which products truly live up to the hype. Start reading now. > >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > >_______________________________________________ > >Ramp-devl mailing list > >Ram...@li... > >https://lists.sourceforge.net/lists/listinfo/ramp-devl > > > > > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Ramp-devl mailing list > Ram...@li... > https://lists.sourceforge.net/lists/listinfo/ramp-devl > |
|
From: Matt P. <pa...@cu...> - 2005-03-29 21:35:24
|
Its not so much the design, more of how to marry the previous concept that Ramp was built around, to the new concept. I found a way that works, but it feels hacky and I keep thinking there is a better way. Ignoring the java aspect the problem lays out like this. Previously I had a stream of bytes and a hard coded structure for turning them back into a data structure. You grab the first byte, that tells you the message, then you construct the necessary objects and hydrate them with the bytes. Its assumed that each message has a determinable number of bytes and that can't change. The problem now is with this block. I have a block of bytes and if I take my block of bytes and start to hydrate the data structure, I could very well run out of bytes to use. So now I'm stuck. I had thought about getting an exact size for each message and then checking to make sure I have enough bytes before hydration, if not, then I grab more bytes. The problem here is with strings and UTF-8. I'm still searching for a way to tell how much of those bytes are to be transformed into the appropriate number of characters. I'm sure this is possible, and with some generated size methods I could figure out how many bytes each message is suppose to have. This is nice also because its very similar to the C version. I had also thought about making the buffer giant, but this just postpones the problem till something really large shows up. Other ideas? One thing is for sure, that some good unit test need to be drawn up to put this together properly. -M Ben wrote: >I'm unfamiliar with java in general and NIO in particular, but I have >worked with asynch i/o before, and it sounds like that's what you're >talking about. I can offer general suggestions of how to deal with that. > >On Tue, 29 Mar 2005, Matt Paulin wrote: > > > >>Wouldn't that make a superior title for a O'Relly book? I can image it >>would be equally stocked with good excuses as information. Just think >>you could tell your boss. Sure the server died, but did you see the >>drama and could you feel the pain of its death. >> >>Thats not really here nor there, but in working with NIO I have been >>thinking about this a bit. Seems there are many ways to screw it up, >>and only lots of testing will fix it. >> >>So I have been converting from the old IO with data input and output >>stream to the NIO stuff. Pretty interesting really, gives you tons of >>control. For instance, now I can totally control what character set is >>being sent, for instance, we are using UTF-8. THat was your only choice >>with regular IO operations. Now I can do all sorts of stuff. Not >>really very useful though, considering UTF-8 is one of the best. >> >>Now if anyone is interested in how to work with NIO, I could certainly >>use the review and ideas. I'm thinking it will need a bit of unit >>testing as well. So far I have seen a place or two where a thread pool >>would be handy for spinning off messages that just arrived. Also NIO >>uses this block transfer analogy instead of the stream analogy. It >>makes more sense, probibly wraps the whole thing into a packet to send >>it. But, its really tricky to unmarshal a block expecially if you only >>got half of the peices in your limited size buffer. My work around >>right now has been to pump the bytes out of the block into a stream and >>then just use the stream. That doesn't seem to be the best way, but is >>appears to be working. >> >>Anyway, its pretty cool stuff, but will take some innovation and ideas >>to make it really effective. Marcus if you are any of your crew are >>interested I could use the review and discussion. Until then I think I >>will just plan to fail gracefully. >> -M >> >> >> >>------------------------------------------------------- >>SF email is sponsored by - The IT Product Guide >>Read honest & candid reviews on hundreds of IT Products from real users. >>Discover which products truly live up to the hype. Start reading now. >>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >>_______________________________________________ >>Ramp-devl mailing list >>Ram...@li... >>https://lists.sourceforge.net/lists/listinfo/ramp-devl >> >> >> > > > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click >_______________________________________________ >Ramp-devl mailing list >Ram...@li... >https://lists.sourceforge.net/lists/listinfo/ramp-devl > > |
|
From: Ben <be...@si...> - 2005-03-29 21:25:05
|
I'm unfamiliar with java in general and NIO in particular, but I have worked with asynch i/o before, and it sounds like that's what you're talking about. I can offer general suggestions of how to deal with that. On Tue, 29 Mar 2005, Matt Paulin wrote: > Wouldn't that make a superior title for a O'Relly book? I can image it > would be equally stocked with good excuses as information. Just think > you could tell your boss. Sure the server died, but did you see the > drama and could you feel the pain of its death. > > Thats not really here nor there, but in working with NIO I have been > thinking about this a bit. Seems there are many ways to screw it up, > and only lots of testing will fix it. > > So I have been converting from the old IO with data input and output > stream to the NIO stuff. Pretty interesting really, gives you tons of > control. For instance, now I can totally control what character set is > being sent, for instance, we are using UTF-8. THat was your only choice > with regular IO operations. Now I can do all sorts of stuff. Not > really very useful though, considering UTF-8 is one of the best. > > Now if anyone is interested in how to work with NIO, I could certainly > use the review and ideas. I'm thinking it will need a bit of unit > testing as well. So far I have seen a place or two where a thread pool > would be handy for spinning off messages that just arrived. Also NIO > uses this block transfer analogy instead of the stream analogy. It > makes more sense, probibly wraps the whole thing into a packet to send > it. But, its really tricky to unmarshal a block expecially if you only > got half of the peices in your limited size buffer. My work around > right now has been to pump the bytes out of the block into a stream and > then just use the stream. That doesn't seem to be the best way, but is > appears to be working. > > Anyway, its pretty cool stuff, but will take some innovation and ideas > to make it really effective. Marcus if you are any of your crew are > interested I could use the review and discussion. Until then I think I > will just plan to fail gracefully. > -M > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Ramp-devl mailing list > Ram...@li... > https://lists.sourceforge.net/lists/listinfo/ramp-devl > |
|
From: Matt P. <pa...@cu...> - 2005-03-29 20:53:23
|
Wouldn't that make a superior title for a O'Relly book? I can image it would be equally stocked with good excuses as information. Just think you could tell your boss. Sure the server died, but did you see the drama and could you feel the pain of its death. Thats not really here nor there, but in working with NIO I have been thinking about this a bit. Seems there are many ways to screw it up, and only lots of testing will fix it. So I have been converting from the old IO with data input and output stream to the NIO stuff. Pretty interesting really, gives you tons of control. For instance, now I can totally control what character set is being sent, for instance, we are using UTF-8. THat was your only choice with regular IO operations. Now I can do all sorts of stuff. Not really very useful though, considering UTF-8 is one of the best. Now if anyone is interested in how to work with NIO, I could certainly use the review and ideas. I'm thinking it will need a bit of unit testing as well. So far I have seen a place or two where a thread pool would be handy for spinning off messages that just arrived. Also NIO uses this block transfer analogy instead of the stream analogy. It makes more sense, probibly wraps the whole thing into a packet to send it. But, its really tricky to unmarshal a block expecially if you only got half of the peices in your limited size buffer. My work around right now has been to pump the bytes out of the block into a stream and then just use the stream. That doesn't seem to be the best way, but is appears to be working. Anyway, its pretty cool stuff, but will take some innovation and ideas to make it really effective. Marcus if you are any of your crew are interested I could use the review and discussion. Until then I think I will just plan to fail gracefully. -M |
|
From: Matt P. <pa...@cu...> - 2005-03-10 21:03:59
|
Just finished added default values for constant sets.
So now when you define a set
<GR:set name="LostPasswordResponseType" default="UNKNOWN_USER"
description="An enumeration of the possible responses from the server
regarding a lost password">
<GR:constant name="LOST_PASSWORD_ACKNOWLEDGED" value="0"
description="The lost password was acknowledged and is being remedied" />
<GR:constant name="UNKNOWN_USER" value="1" description="The user
specified was unknown" />
</GR:set>
A default has to be added. This helps out a bunch when conversions
happen. Previously I could end up with nulls because the converter
didn't know what to turn corner cases into.
-M
|
|
From: Matt P. <pa...@cu...> - 2005-03-09 16:26:08
|
Oh I fixed it, the message anyway. Its a bit more descriptive. -M Matt Paulin wrote: > Its best to use the bug tracking system supplied with sourceforge. > > Yes, thats a cryptic error :) > > Its telling you that you are using a value of 250 when you have told > it that the element is a byte. I believe > the way it interprets a byte is as a signed byte. So 128 is your max. > -M > > > > > What"s the preferred bug-tracking method for ramp? SF.net? > > For instance, I just found out that this cryptic error message means > "the constant is too big for the data type". At least, I think that"s > what it"s telling me, because that was the case..... > > [java] ERROR : The element [remainingInvites] in the parent > [ReplaceInvitesRemaining] is using the non number max value [250]. > > > On Mar 8, 2005, at 8:27 PM, Matt Paulin wrote: > > > This is the first email to this list, > > > > I know of 4 folks on here at the moment. Ben and Dutch have done > > previous work building the C bindings for Ramp, I did the Java > > bindings. Marcus and his friend have an interest in Eclipse and I"m > > not sure what else. > > Anyway, this project has been very useful toward us for other > projects > and its been in a holding pattern for the last half year. > Recently we > have been finding new work that needs to be done on it > and Dutch/I > will be adding that functionality. > > > > Heres a quick rundown of whats been built and where we are going. > > > > Ramp takes an XML protocol file and pipes it through a code > generator > to form an API for the language of your choice. This is > assuming that > you would either choose Java or C at this point. In > terms of java > there is one type safe api, and a message api. The > message one is > better for servers where as the type safe one is more > useful for > building clients. There is also a system testing harness > that can be > generated so that a person can build system level test > for testing a > server that is being connected to using a ramp > protocol. Finally we > have a documentation generator that turns the > protocol into a html > file, sorta looking like javadoc. > > > > For testing we have a small harness that lets us test a series of > > cases and features that we have integrated. > > > > Seems small but, it was a bit of work to get this far. So far we > have > seen it behave very well, but, its still rather young. > > > > So coming up we are trying to work on the hand shaking, and allow an > > option to have the protocol encrypted between client and server. As > > of right now its clear text and thats just silly. We also have a > bit > of tweaking todo on the generated C code to tighten it up and > make it > more secure. > > Now there is a lot of room open for new possibilities. For > instance, > I have been thinking a lot of a php binding. Also there > has been talk > of a python binding. It will be rather fun to have > php talking to a > java server that talks to a C server all via ramp. > Sorta silly but, > in some cases maybe that would be useful. Another > thing is building > tools that will allow the ramp file to be edited > easier. It would > also be nice to have a way to watch what messages > are passing back and > forth to aid in debugging. I have some of this > figured out already, > but not generalized enough. > > > > Anyway, my plan is to just send a weekly update to this list and > tell > everyone where we are at the moment. If anyone wants to join > in the > fray, please don"t be shy and just talk to me first about > your ideas. > > > > Cheers, > > -Matt > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real > > users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > <http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click> > > _______________________________________________ > > Ramp-devl mailing list > > Ramp-devl@li... > > https://lists.sourceforge.net/lists/listinfo/ramp-devl > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Ramp-devl mailing list > Ram...@li... > https://lists.sourceforge.net/lists/listinfo/ramp-devl |
|
From: Matt P. <pa...@cu...> - 2005-03-09 16:22:44
|
Its best to use the bug tracking system supplied with sourceforge. Yes, thats a cryptic error :) Its telling you that you are using a value of 250 when you have told it that the element is a byte. I believe the way it interprets a byte is as a signed byte. So 128 is your max. -M What"s the preferred bug-tracking method for ramp? SF.net? For instance, I just found out that this cryptic error message means "the constant is too big for the data type". At least, I think that"s what it"s telling me, because that was the case..... [java] ERROR : The element [remainingInvites] in the parent [ReplaceInvitesRemaining] is using the non number max value [250]. On Mar 8, 2005, at 8:27 PM, Matt Paulin wrote: > This is the first email to this list, > > I know of 4 folks on here at the moment. Ben and Dutch have done > previous work building the C bindings for Ramp, I did the Java > bindings. Marcus and his friend have an interest in Eclipse and I"m > not sure what else. > Anyway, this project has been very useful toward us for other projects > and its been in a holding pattern for the last half year. Recently we > have been finding new work that needs to be done on it and Dutch/I > will be adding that functionality. > > Heres a quick rundown of whats been built and where we are going. > > Ramp takes an XML protocol file and pipes it through a code generator > to form an API for the language of your choice. This is assuming that > you would either choose Java or C at this point. In terms of java > there is one type safe api, and a message api. The message one is > better for servers where as the type safe one is more useful for > building clients. There is also a system testing harness that can be > generated so that a person can build system level test for testing a > server that is being connected to using a ramp protocol. Finally we > have a documentation generator that turns the protocol into a html > file, sorta looking like javadoc. > > For testing we have a small harness that lets us test a series of > cases and features that we have integrated. > > Seems small but, it was a bit of work to get this far. So far we have > seen it behave very well, but, its still rather young. > > So coming up we are trying to work on the hand shaking, and allow an > option to have the protocol encrypted between client and server. As > of right now its clear text and thats just silly. We also have a bit > of tweaking todo on the generated C code to tighten it up and make it > more secure. > Now there is a lot of room open for new possibilities. For instance, > I have been thinking a lot of a php binding. Also there has been talk > of a python binding. It will be rather fun to have php talking to a > java server that talks to a C server all via ramp. Sorta silly but, > in some cases maybe that would be useful. Another thing is building > tools that will allow the ramp file to be edited easier. It would > also be nice to have a way to watch what messages are passing back and > forth to aid in debugging. I have some of this figured out already, > but not generalized enough. > > Anyway, my plan is to just send a weekly update to this list and tell > everyone where we are at the moment. If anyone wants to join in the > fray, please don"t be shy and just talk to me first about your ideas. > > Cheers, > -Matt > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click <http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click> > _______________________________________________ > Ramp-devl mailing list > Ramp-devl@li... > https://lists.sourceforge.net/lists/listinfo/ramp-devl |
|
From: Ben <be...@si...> - 2005-03-09 04:34:46
|
What's the preferred bug-tracking method for ramp? SF.net? For instance, I just found out that this cryptic error message means "the constant is too big for the data type". At least, I think that's what it's telling me, because that was the case..... [java] ERROR : The element [remainingInvites] in the parent [ReplaceInvitesRemaining] is using the non number max value [250]. On Mar 8, 2005, at 8:27 PM, Matt Paulin wrote: > This is the first email to this list, > > I know of 4 folks on here at the moment. Ben and Dutch have done > previous work building the C bindings for Ramp, I did the Java > bindings. Marcus and his friend have an interest in Eclipse and I'm > not sure what else. > Anyway, this project has been very useful toward us for other projects > and its been in a holding pattern for the last half year. Recently we > have been finding new work that needs to be done on it and Dutch/I > will be adding that functionality. > > Heres a quick rundown of whats been built and where we are going. > > Ramp takes an XML protocol file and pipes it through a code generator > to form an API for the language of your choice. This is assuming that > you would either choose Java or C at this point. In terms of java > there is one type safe api, and a message api. The message one is > better for servers where as the type safe one is more useful for > building clients. There is also a system testing harness that can be > generated so that a person can build system level test for testing a > server that is being connected to using a ramp protocol. Finally we > have a documentation generator that turns the protocol into a html > file, sorta looking like javadoc. > > For testing we have a small harness that lets us test a series of > cases and features that we have integrated. > > Seems small but, it was a bit of work to get this far. So far we have > seen it behave very well, but, its still rather young. > > So coming up we are trying to work on the hand shaking, and allow an > option to have the protocol encrypted between client and server. As > of right now its clear text and thats just silly. We also have a bit > of tweaking todo on the generated C code to tighten it up and make it > more secure. > Now there is a lot of room open for new possibilities. For instance, > I have been thinking a lot of a php binding. Also there has been talk > of a python binding. It will be rather fun to have php talking to a > java server that talks to a C server all via ramp. Sorta silly but, > in some cases maybe that would be useful. Another thing is building > tools that will allow the ramp file to be edited easier. It would > also be nice to have a way to watch what messages are passing back and > forth to aid in debugging. I have some of this figured out already, > but not generalized enough. > > Anyway, my plan is to just send a weekly update to this list and tell > everyone where we are at the moment. If anyone wants to join in the > fray, please don't be shy and just talk to me first about your ideas. > > Cheers, > -Matt > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Ramp-devl mailing list > Ram...@li... > https://lists.sourceforge.net/lists/listinfo/ramp-devl |
|
From: Matt P. <pa...@cu...> - 2005-03-09 04:25:35
|
This is the first email to this list, I know of 4 folks on here at the moment. Ben and Dutch have done previous work building the C bindings for Ramp, I did the Java bindings. Marcus and his friend have an interest in Eclipse and I'm not sure what else. Anyway, this project has been very useful toward us for other projects and its been in a holding pattern for the last half year. Recently we have been finding new work that needs to be done on it and Dutch/I will be adding that functionality. Heres a quick rundown of whats been built and where we are going. Ramp takes an XML protocol file and pipes it through a code generator to form an API for the language of your choice. This is assuming that you would either choose Java or C at this point. In terms of java there is one type safe api, and a message api. The message one is better for servers where as the type safe one is more useful for building clients. There is also a system testing harness that can be generated so that a person can build system level test for testing a server that is being connected to using a ramp protocol. Finally we have a documentation generator that turns the protocol into a html file, sorta looking like javadoc. For testing we have a small harness that lets us test a series of cases and features that we have integrated. Seems small but, it was a bit of work to get this far. So far we have seen it behave very well, but, its still rather young. So coming up we are trying to work on the hand shaking, and allow an option to have the protocol encrypted between client and server. As of right now its clear text and thats just silly. We also have a bit of tweaking todo on the generated C code to tighten it up and make it more secure. Now there is a lot of room open for new possibilities. For instance, I have been thinking a lot of a php binding. Also there has been talk of a python binding. It will be rather fun to have php talking to a java server that talks to a C server all via ramp. Sorta silly but, in some cases maybe that would be useful. Another thing is building tools that will allow the ramp file to be edited easier. It would also be nice to have a way to watch what messages are passing back and forth to aid in debugging. I have some of this figured out already, but not generalized enough. Anyway, my plan is to just send a weekly update to this list and tell everyone where we are at the moment. If anyone wants to join in the fray, please don't be shy and just talk to me first about your ideas. Cheers, -Matt |
2 messages has been excluded from this view by a project administrator.
