-
This project is still being developed, albeit very slowly. I've just upgrade to Tiger and intend to run through some basic regression testing soon.
My long-planned clean rewrite hasn't happened; I've been focusing on my Keychain framework, since there's been relatively significant interest in that compared to SDO. I people are interested in SDO, please do drop me a line and vote for my...
2005-05-10 03:55:51 UTC by wadetregaskis
-
Enjoying the new freedom I have, given that resolution of the worst two programming 'bugs' I've ever faced, I've done a great deal of work on the project over the past few days. Check the release notes for all the details.
Most important for most people, I presume, is that the project no longer depends on the Keychain framework to build and use. It still supports it's use, however, if it...
2003-10-20 13:05:39 UTC by wadetregaskis
-
Logged In: YES
user_id=735766
Fixed - the new control protocol sends a close message prior
to a graceful close, to give the other side appropriate
notification.
2003-10-20 13:00:03 UTC by wadetregaskis
-
That's right, it works properly now. And the solution to the two major bugs turns out to be have been even more elegant than I anticipated - thus, I'm pretty sure I've squished a whole host of other potential bugs in the process.
The 16th of October [2003] release is the working version. I consider it the first alpha. Please check it out, test it, submit bug reports/fixes, etc. But don't...
2003-10-16 13:10:22 UTC by wadetregaskis
-
Logged In: YES
user_id=735766
Well, after all this time, I've finally done it - it works.
I'm still having a hard time conceptualizing the problem [as
it was], but essentially it boils down to the fact that
CFSocket's are not inherently re-entrant, which meant in
order to get anywhere I had to delay the packet decoding
until after the dataAvailable callback exited, using
NSRunLoop's...
2003-10-16 12:52:56 UTC by wadetregaskis
-
Logged In: YES
user_id=735766
Here's some more info on the problem. What seems to be
happening is that the reply is being dispatched fine, and
the NSConnection is receiving it. However, sendInvocation
still sits there for a while, until it times out. It then
realizes it has a reply, and everything goes well until the
next occurance of this problem.
Specifically, here's some relevant...
2003-10-15 14:45:11 UTC by wadetregaskis
-
If anyone's been following the bugs, they'll have noticed the ones stating simply that the port doesn't work have been closed and marked as fixed. Funny about that.
Yes indeed, the port now works properly in all the normal uses I've tested it for. There is a fairly significant bug still remaining, whereby there are random and frequent delays in the messaging cycle, but I'm confident these...
2003-10-13 14:49:52 UTC by wadetregaskis
-
With the new method of delaying the decodePacket method
until the dataAvailable method exits, there are now
sometimes significant delays, apparently somewhere
inbetween receiving the data and passing off the port
coder. These are no doubt due to this delayed method
call becoming too delayed for some reason - why this
I'm not sure. Perhaps the priority simply needs to be
increased, to...
2003-10-13 14:44:49 UTC by wadetregaskis
-
Logged In: YES
user_id=735766
While it's far from finished, it does at least work now, by
most accounts. Thus, I'm considering this bug fixed and
closed. If you can't get the port to work at all, file a
new bug report - it's probably a different issue.
2003-10-13 14:41:47 UTC by wadetregaskis
-
Logged In: YES
user_id=735766
It seems my hunch was absolutely correct! The port now
works completely in my limited example - messages that
desire replies get them, and all is well! Well, mostly...
there's a new bug in this area to work on now, but at least
progress is being made.
2003-10-13 14:40:57 UTC by wadetregaskis
