[Gambas-user] Socket Limitations
Kadaitcha Man
nospam.nospam.nospam at ...626...
Mon Jan 4 12:45:06 CET 2010
2010/1/4 Doriano Blengino <doriano.blengino at ...1909...>:
> Kadaitcha Man ha scritto:
>> 2010/1/4 Doriano Blengino <doriano.blengino at ...1909...>:
>>
>>
>>> My idea was to raise an event when a line has been read
>>>
>>
>> Based on what I just posted to the developer's list, you will need to
>> be specific about what defines an end of line. For example:
>>
>> NUL ^@ \0 Null character
>> ETX ^C End of Text
>> LF ^J \n Line feed
>> CR ^M \r Carriage return
>> ETB ^W End of Trans. Block
>>
>> Or, a combination of characters, such as \r\n.
>>
> To accomplish this task (event when a whole line has been read), there
> would be a string property, containing the characters you want as EOL,
> or another sequence, or even the terminator "CRLF.CRLF". The program
> would set this property to what it pleases to.
Yes, fine.
> Actually, it is a little too easy to suggest things without trying to
> develop them; I did it just a few messages ago, and I comprehend that
> before implementing a new feature Benoit has to take in account other
> factors, for example compatibility with previous versions, reliability,
I know that counts for something, but gb3 is alpha, so major changes
should be expected. Furthermore I have seen announcements for gb2 that
essentially say, "If you use this version, things will break!" That
aside, yes, Benoit has other things to consider.
> "strangeness" of some solution. This feature for reading lines or blocks
> is a little strange, I suppose.
I don't think so. Read on to find out why.
> My problem is that I see some gambas
> limitations, but it would be wrong to try to turn gambas in something
> else which was not the original intention.
Well, no. Things do change and evolve. Again, that aside, it's
Benoit's decision.
> For my extravagant ideas,
> there would exist a totally new language - a mix of Tcl, Python and
> Perl.
If, for that, Benoit were to suggest that you should be shipped to a
former USSR psikhushka in the furthest Arctic reaches of outer
Siberia, given high doses of mind-altering drugs and punished severely
for your mental illness, I would agree with him :)
> So I think I must calm myself;
Given the fate I would support for you, that's probably a very good idea :)
> take gambas for what it is, knowing
> that is not perfect for me, but good enough for a lot of people (me
> included).
Gambas is far, far, faster than VB.NET. Many things are accomplished
with much less code. Gambas has allowed me to finally get off Windows
after many years of being tied down. That said, the differences
between gb and VB have made me think very hard, which I also
appreciate. One can too easily become mentally lazy, and IMO the worst
of humanity are the mentally lazy,
> I think that Benoit welcomes different points of view, but correctly he
> takes those advices with a grain (or a handful?) of salt.
I'm sure Benoit is a fine student of common sense.
> With regards to our discussion, I see that our three points of view are
> not so different,
No, they are not.
> and I enjoyed it.
Et moi.
Mon français sucks, vous savez, mais le bon côté, je sais avec
certitude que je peux obtenir mon visage giflé par une femme française
tout moment que je choisis.
<really cheeky grin>
> Gambas3 (which I never tried) is not
> yet stable,
It is not yet officially stable, and it has some strange anomalies in
the editor, which I m compiling a dossier on, but for me, it is stable
enough to stick with. Unless you don't mean stable as in crashing.
> so it is forgivable for its glitches;
Well, despite my very bad manners and rudeness, I do want to help gb3 succeed.
> I think that there is
> something extreme in trying to send large chunks of data in a single
> instruction,
Weeeelllllll... Not necessarily. If the document is imprecise, which
it most definitely is, it is fair to make assumptions then complain
loudly to the developers when you find out that your assumptions are
wrong.
As for actually addressing your point, perhaps you are right, it may
be extreme, but as it stands, gb3 does not allow for sending "large
chunks of data in a single instruction" unless blocking is on. The
whole point of what I was saying earlier is that gb3 has no mechanism
for managing the transfer of such large blocks without blocking.
I am communicating with RFC 3977 compliant servers and there is no
defined limit on file size in RFC 3977. What limits the size of a
single data transfer is the reliability of the connection between the
server and the client. That puts the onus on me to test various
configurations and to arrive at a file size that can be reliably
transferred. FWIW, I would not go beyond 512k, even with today's
technology.
> but I must also stop to think in the terms of twenty years
> ago
Try fifty and then you're really on the playing field.
> - computers, OSes and languages *must* be more powerful. So,
> blocking mode by default and a reasonable set of "normal" properties and
> events, like all the other languages and OSes do, could be a safe way.
I disagree. I cut my teeth on fortran and COBOL, both are in use
today, and AAMOF, I believe it is still true that no language can
approach the usage levels of current day COBOL to even this very day.
The point? Languages evolve as and when they need to.
> You say that an event for reading single lines from a socket would
> improve your programs: well, probably it is already possible to do so,
It would not actually "improve" my programs. It would make my life as
a programmer much easier because, despite your limited view into the
future, there are still highly popular systems to be communicated with
that are barely two years older than myself.
> I had to explain my mind; I suggest, advise and criticize mainly trying
> to be cooperative, but sometimes things go too much over.
Oh, look, my rudeness is intended to provoke a thoughtful response.
You can either react to the attitude or you can deal with the problem
I present. It's my way of sorting out the wheat from the chaff. You're
amongst the wheat :)
More information about the User
mailing list