It has full support. Of course features added to WebKit after OWB development was stopped by Sand-Labs/Pleyo can't work.
It crashes on security websocket's tests with DSI/nullpointer (while should't) as well as html5test.com says your version have "partial" support (but that can be of course because of webkit in your owb which are years old, but crashes on security checks are bad for sure): while for odyssey, html5test says it have full websockets support, and didn't crashes on secutrity websockets (but security ones also didn't works anyway, just pure disconnect, but that still better than crash, of course).
@Fab Do you have any problems if i will just rename "owb" binary to "odyssey" so joerg be happy and can help with websockets fix ? I mean, will it stop factor for you to continue share sources if i will do so, or you have no problems with ? I just do not want to loose my time (and have no big interest in general) to fix myself that websockets crap, while joerg know the solution and just do not want to say how to fix it because of that boring moment about arexx port (which for me, does not matter at all, i even can call it omiga1200.exe).
At least for me, i see no reassons why Joerg worry at all about name clashes, if he didn't update his owb for years and never will. Just sounds a bit strange imho to worry about no-more-in-developer-version. But , if pure rename will bring us websocket's fix , them i have no problems myself to rename it, if you (fab), have no problems with it too, and that will be no stop factor to share sources of next versions.
Of course i can keep it as it, and fix it myself, but that will take more time, besides if joerg already know how to fix it and his version prove that he make it works.
Btw, i even yesterday tried to start build mos version (to enable debug in websockets and to see differences, and so can get what wrong and how it should looks like), and (of course it was expected) start to meet with problems with morphos cross-compiler, which i didn't have with aos4 cross compiler : i.e. cmake by some reassons fail to found ppc-morphos-g++, while, i can run it from shell and make binaries fine, and i even see that cmake-test also compile binary fine, but still says that can't find compiler. I will happy skip all that boring crap if pure renameing of "owb" to "odyssey" will give us necessary code changes to have working websockets.
EDIT: Only today found that on cygwin, i need for morphos use exactly ppc-morphos-gcc-4.4.5.exe and ppc-morphos-g++-4.4.5.exe (with .exe at end) in morphos.cmake, as for example pure ppc-morphos-g++/ppc-morphos-gcc or pure ppc-morphos-g++-4.4.5/ppc-morphos-gcc-4.4.5 make cmake fail. At least now it start compiles.
And to add to all bunch of problems, i found lately, that 1.23 from time to time crashes on Javascript in blockfree, when i exit from odyssey. Not offten, but from time to time. With 0xCCCCCCC too.
Edited by kas1e on 2014/2/22 14:03:55 Edited by kas1e on 2014/2/22 14:07:40 Edited by kas1e on 2014/2/22 14:08:09 Edited by kas1e on 2014/2/22 14:29:15 Edited by kas1e on 2014/2/22 14:29:31
Do you have any problems if i will just rename "owb" binary to "odyssey"
I can't see any reason why you even need to ask fab about this? Ofcourse for politeness sake maybe, but you are making an AmigaOS 4 port of the program ans the reasons to change it are exactly the same as the reasons to keep it the same on morphos. ie that OS 4 is configured to use OWB for Joergs program by default. The supplied scripst can be easily fixed, changing a port name in a script is trivial.
Yes, he is asking out of courtesy. What you should be more focused on analyzing is why Joerg is acting that way when he was very well paid for a pretty crappy browser.
That is a little unfair. Software evolves, with later versions often making the first releases pale by comparison. I remember using Joergs browser and finding it a delight compared to those that it replaced. If we want Joergs contributions to resume, then referring to his work in such a derogatory way is a sure way to block that.
@magnetic It was good enough when Joerg works on it, and for example font handling done much better than in odyssey still (without usage of that fontconfig), and i even reuse in last ports of odyssey his work: native mouse pointers (in 1.9 already) and support of locales and threaded curl (in 1.16 and now in 1.23 too). Sure i also wish that he didn't act like that just because of that arexx thing, but from another side he spend lots of time on, and want to protect it all somehow to avoid side effects. I even hope he someday will add new webkit code to it, and add (at last) download manager , and will not say owb is not browsers, as users do not care about how it call and what is it, they just want modern webkit core + gui at top of it. But, i assume it will not happens as he have no time/motivation for, imho.
@all Start some debugging by printing stuff in platformsend():
long socket;
CURLcode result = curl_easy_getinfo(m_curlHandle, CURLINFO_LASTSOCKET, &socket);
ASSERT_UNUSED(result, result == CURLE_OK);
And when we do connect on websocket.org that what we have:
Quote:
platformSend 0x6319F0F0 platformSend lengthSend = -1 platformSend length = 665 platformSend Error sending: Bad file number
So "::send" fail to send, and errno says "bad file number", which can mean invalid descriptor or so i assume (as there is no file at all, we just send data to).
That "crappy browser" is still my main web browser (combined with OWBUtilities tool set), that does more or less everything I need. It's fast, rather light weighted and still has the best font rendering from all available alternatives.
@kas1e, many years are passed from my c++ programming days, but in your file BCSocketStreamHandleBaseWK.cpp I cannot see a send method with the parameters you are using in the call, the only send I see it's: bool SocketStreamHandleBase::send(const char* data, int length) which lack the first parameter, the socket, maybe it's a define, but not having all the includes it's difficult to say and a code like this I think that cannot be compiled
@pvanni There is few more "send" in websocket files, but all of them have different set of params. And as i know nothing about c++ , i leave it for those skilled ppls who know it.
@magnetic You don't have ANY idea how much work Joerg put into (what was at the time) the most modern & standards-compliant Amiga web browser available. He was the first person to make a usable port of the WebKit engine on any Amiga-like platform, which was no small feat considering the size & complexity of the source code.
It is a real shame that he only ever saw OWB as a "stop gap" solution, until someone ported a 'real' (fully featured) web browser to AmigaOS4, but that's his perogative.
Any monies sent to him were gifts to thank him for all the work he had done. I myself sent him a fairly sizable donation shortly before he announced stopping work on OWB.
@pvanni Basically as i read, "::function" in c++ , mean to call function outside of any namespaces, so in our case i assume it call socket's one (imho done like this just to be 100 sure that socket's one are called). There just few sends in some classes in webcore, so they do it like this only for send() and not for recv() for example.
But now question is why it fail and why lengthSend = -1. Just like socket descriptor wrong or kind.
Which it's the value of socket after the curl_easy_getinfo call? All send that i can find in internet has the first parameter "int" but curl_easy_getinfo take a pointer to long, but it doesnt compile without an explicit cast, so probabily I havent found the right send() over the net. From the libcurl documentation if I understand right curl_easy_getinfo return CURLE_OK if the call was successful but socket can be -1 if it's no longer valid
He was the first person to make a usable port of the WebKit engine on any Amiga-like platform, which was no small feat considering the size & complexity of the source code.
No, he wasn't... Marcik brought WebKit to an amiga-like platform years before that, and with a usable GUI, too. And it was much more work at that time, because there weren't SDL or Cairo backends that made WebKit so easy to port.
@kas1e
I won't even comment on Joerg's nonsense about malware and naming. You can rename if you want, but you're on your own if you have issues later with software depending on that, because i'll keep OWB on my side.
And about your actual issue, it's rather suspicious send() fails if connect() really succeeded. All this happens in main thread context, so unless the socket was already closed before or that the socket descriptor value got changed, i fail to see how it could happen. Maybe your CURL port has an impact on that somehow, though, to be checked.
Anyway, you can askJoerg now, i'm sure he will help. :) But just for your information, since June 2010 (i.e the WebKit revision OWB Reaction is based on), WebKit got more than 100000 revisions. There were *many* API changes in backends as well.
Maybe your CURL port has an impact on that somehow, though, to be checked.
All i do with curl port, its only add to it changes realted to URI you send me years ago (that file.c), and to make threaded resolver works add for each get_host_byname opening of new instanse of bsdsocket.library. And that change related to ssl cert to have PROGDIR: for. And that all.
But as i say, curl binary which i build from that library, works fine with websockets.
Quote:
And about your actual issue, it's rather suspicious send() fails if connect() really succeeded. All this happens in main thread context, so unless the socket was already closed before or that the socket descriptor value got changed, i fail to see how it could happen. Maybe your CURL port has an impact on that somehow, though, to be checked.
Yes, its clear now that send() fail, and seems because of "bad socket".
I go further and add more debug, my current whole platformsend():
int SocketStreamHandle::platformSend(const char* data, int length)
{
D(kprintf("platformSend %p\n", this));
LOG(Network, "SocketStreamHandle %p platformSend", this);
if (!m_curlHandle)
return 0;
RefPtr<SocketStreamHandle> protect(this);
long socket;
D(kprintf("platformSend socket before curl_easy_getinfo = %08x\n", socket));
D(kprintf("platformSend data before curl_easy_getinfo = [%s]\n", data));
CURLcode result = curl_easy_getinfo(m_curlHandle, CURLINFO_LASTSOCKET, &socket);
D(kprintf("platformSend socket after curl_easy_getinfo = %08x\n", socket));
D(kprintf("platformSend data after curl_easy_getinfo = [%s]\n", data));
D(kprintf("platformSend curl_easy_getinfo result ='%s'\n", curl_easy_strerror(result)));
So, as far as i can see, "data" ok before and after (so we pass it ok). Length is ok too. curl_easy_getinfo also says no error (but as google says: The curl_easy_getinfo processing for CURLINFO_LASTSOCKET returns the last socket without regard to its current status, so our socket can be closed already or kind).
And in end of all, with what we now its that socket is bugged. I.e. that one, to which we trying to send are wrong one. We connects , prepare everything to send, and then send just fail with "bad file number" which again can mean bad socket handle (or right one, just closed already by some reasons).
Its like error in the whole logic, and just looks like socket is closed somewhere somehow before. And curl_easy_getinfo didn't fail, as "socket without regard to its current status". And socket's handles also looks ok too.
@pvanni Quote:
From the libcurl documentation if I understand right curl_easy_getinfo return CURLE_OK if the call was successful but socket can be -1 if it's no longer valid
Google says that "The curl_easy_getinfo processing for CURLINFO_LASTSOCKET returns the last socket without regard to its current status", so socket can be bad already, just last one, curl_easy_getinfo didn't check if it open and still valid as i see
Edited by kas1e on 2014/2/25 11:47:54 Edited by kas1e on 2014/2/25 12:26:28 Edited by kas1e on 2014/2/25 12:27:57 Edited by kas1e on 2014/2/25 12:28:45
That "ThreadableWebSocketChannel" can't be something which trash socket (and so we need still to open there ISocket on os4 always for each call to this?)
@kas1e Unless the socket descriptor is trashed, the code probably calls newlib's send instead of the one from bsdsocket.library. You might want to call ISocket->send instead of ::send, just to make sure you are not calling the newlib one.
Unless the socket descriptor is trashed, the code probably calls newlib's send instead of the one from bsdsocket.library. You might want to call ISocket->send instead of ::send, just to make sure you are not calling the newlib one.
No, his bug is the other way round (using ISocket->send() instead of newlib send() because he is compiling with __USE_INLINE__), libcurl is using the C library sockets. The reason for the bug is the same as for 90% of the bugs in his builds: He is simply trying to compile MorphOS code with -D__USE_INLINE__ instead of porting Odyssey to AmigaOS. In this case for example #ifdef __morphos__/#endif is missing around #include proto/socket.h.
when he was very well paid for a pretty crappy browser.
I wasn't paid for the OWB port. If you think it was crappy you should have complained to sand-labs/pleyo, I always made it 100% clear that it's an AmigaOS port of OWB and that I wont implement a complete desktop browser around it. If you didn't like that you could have done something else yourself with it, it's open source and the AmigaOS parts were on the OWB SVN (unlike for example the AROS ones).
I think its just better if we just let past be the past here, it serves no one to start arguing about it again. I don't know who deserves a apology here, but many things where was said, that should not haven been said, and that I think include everyone including Joerg and Me.
I don't know if there is a lesson to be learned here or not, but maybe we should be more polite to word etch other, arguing about things, name calling and so on, never made things better.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
