A few of you may recognize me from the recent posts I have made about Indy
<http://www.indyproject.org/indy.html>
Those of you coming to .net from the Delphi world know truly how unique and
"huge" Indy is both as a project, in support, development, and use. But
Indy is new to the .net world.
Indy is a HUGE library implementing over 120 internet protocols and
standards and comes with complete source. Its an open source project, but
not your typical abandonware type. It has a development team of
approximately 40 people who are very active, a dedicated documentation
team, a dedicated demo team, a support team, commercial support options,
and even a book.
Its hard to simply take someones word for this - especially when the word
is from someone who is not well known in the .net world (yet! :) ).
<http://www.hower.org/Chad/Bio.html>
I currently speak at 6-8 conferences around the world each year as well as
regularly write for Delphi magazines.
But Indy is huge - and even with System.Net.Sockets Indy still has a LOT to
offer. Its like comparing a kitchen knife with Swiss Army's top model
knife.
For some basics you can see:
<http://www.atozed.com/indy/Texts/WhyIndy.iwp>
The team obviously is heavily Delphi based. Many of us are doing C# work as
well because Delphi 8 just arrived and many of us needed .net earlier. And
many of us still cross over back and forth between VS and Delphi.
What we need is some VS users - in this case C# users to join a new team we
are forming. We have not named this team yet, but this team would help us
move foward into the VS / .net (other IDEs) world. Roles will be mixed -
support, input, direction, docs, writing demos, and more. Dont worry - you
dont have to do it all. Thats what a team is about - but everyone can
contribute what they are able too.
Not a guru? It doesnt matter. While we welcome and would love to have some
MVPs and MSCE's on board, we are looking for average Joe's, corporate
developers, students, hobbyists and even the newbie!
Rewards? Well Indy is free. But its a very rewarding experience, as well as
a chance to learn, meet new people, experience new code, and be part of a
team. Best of all to forward a very cool and already successful open source
project!
Previously a Delphi or a current cross over user? If so - you can reply and
lend some credibility to my message for those who have no clue who I am. In
the Delphi world I am fairly well known - but I am a newcomer and do not
have much name recogntion here, and neither does Indy yet.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com 48  3123 
"Chad Z. Hower aka Kudzu" <cp**@hower.org> writes: What we need is some VS users - in this case C# users to join a new team we
are forming. We have not named this team yet, but this team would help us
move foward into the VS / .net (other IDEs) world. Roles will be mixed -
support, input, direction, docs, writing demos, and more. Dont worry - you
dont have to do it all. Thats what a team is about - but everyone can
contribute what they are able too.
What will this team exactly do?
--
Lawrence
I forgot to add:
1) Please redistribute this announcement on other forums, to .net website
webmasters, mailing lists and soon of your choices. Please include this
addendum as well.
2) If you are interested, you can use this form to contact me as I am the
chairman of Mercury Team which is the administrative team for Indy.
<http://www.hower.org/kudzu/Mail.html>
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Lawrence Oluyede <ra***@dot.com> wrote in news:87************@mobile.foo: What we need is some VS users - in this case C# users to join a new
team we are forming. We have not named this team yet, but this team
would help us move foward into the VS / .net (other IDEs) world. Roles
will be mixed - support, input, direction, docs, writing demos, and
more. Dont worry - you dont have to do it all. Thats what a team is
about - but everyone can contribute what they are able too.
What will this team exactly do?
It will evolve. Normally what happens is we assign people to an existing
team. But with VS developers the situation is a bit different.
Initially we will form the team and add all members of core team. Then we
will decide which new teams to form and move people to those, or even
existing teams where it applies. Developers may be on more than one team.
We need help with docs, demos, spreading the word, and more. Its really an
open role - each developer has specific talents and interests. We try to
match.
The difference in this role from others is that unless you know Delphi, you
wont be working on the core assembly much. But we want to put a "inside" team
in contact directly with the developers on a priority basis so we can promote
demo creation, doc help etc.. I would say that demos and just general
knowledge are the most important right now. The docs are pretty portable, so
its not an urgent need but help is always welcome there too. ;)
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote:
<snip> Previously a Delphi or a current cross over user? If so - you can reply and
lend some credibility to my message for those who have no clue who I am. In
the Delphi world I am fairly well known - but I am a newcomer and do not
have much name recogntion here, and neither does Indy yet.
Yep. I used to lurk in borland.public.delphi.internet.winsock and
regularly saw your name in there.
As for Indy, I've used several of its components before and am
impressed with it. It could indeed come in handy for .NET developers
who want tried and trusted code that implements a particular protocol
(for example, NNTP).
"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote: A few of you may recognize me from the recent posts I have made about Indy
<http://www.indyproject.org/indy.html>
<snip>
I guess there aren't many Delphi people here!
C# Learner <cs****@learner.here> wrote in
news:i3********************************@4ax.com: A few of you may recognize me from the recent posts I have made about Indy
<http://www.indyproject.org/indy.html>
<snip>
I guess there aren't many Delphi people here!
There are a few - but there are a LOT of messages (ie noise), and its only
been a few hours, and its Saturday. :)
But really most Delphi people are remaining Delphi. And many of those doing
VS.net development do not hang out in the MS groups. They are pretty friendly
in the .net groups, but the old VS areas were very hostile to Delphites and
just "unfriendly" compared to the Borland areas which has stuck in a lot of
Delphites minds. When I told other Delphites people were friendly here and it
was like the VB 3 days (before Delphi existed) they didnt believe me!
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote: There are a few - but there are a LOT of messages (ie noise), and its only
been a few hours, and its Saturday. :)
But really most Delphi people are remaining Delphi.
Since I'm a student and hobbyist programmer, I have the freedom to
more or less choose any language/framework as I please. I recently
decided to try C#/.NET since it appeared to be a combination of a
language with nice sytax, and a powerful library. Not to mention the
fact that, since Microsoft made it, it's likely to be the next big
programming thing.
In any case, I doubt I'll drop Delphi any time soon, as I've been
using it for years, and still like it. I'll probably give Delphi 8 a
try when I get the chance.
And many of those doing
VS.net development do not hang out in the MS groups. They are pretty friendly
in the .net groups, but the old VS areas were very hostile to Delphites and
just "unfriendly" compared to the Borland areas which has stuck in a lot of
Delphites minds. When I told other Delphites people were friendly here and it
was like the VB 3 days (before Delphi existed) they didnt believe me!
I agree. Just like in the Borland groups, the people here are very
friendly and knowledgeable.
C# Learner <cs****@learner.here> wrote in
news:c0********************************@4ax.com: more or less choose any language/framework as I please. I recently
decided to try C#/.NET since it appeared to be a combination of a
language with nice sytax, and a powerful library. Not to mention the
fact that, since Microsoft made it, it's likely to be the next big
programming thing.
All good and valid points.
In any case, I doubt I'll drop Delphi any time soon, as I've been
using it for years, and still like it. I'll probably give Delphi 8 a
try when I get the chance.
Its very nice. But you might want to wait for the first service pack. I
suspectd its due soon. :)
But the IDE is a "1.0" release if you will. The compiler is what really makes
or breaks it - and that is very very well done for .net.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: A few of you may recognize me from the recent posts I have made about Indy
<http://www.indyproject.org/indy.html>
Those of you coming to .net from the Delphi world know truly how unique and
"huge" Indy is both as a project, in support, development, and use. But
Indy is new to the .net world.
<snip>
I've thought long and hard about this post, and hopefully it won't
cause offence - wherever there are two ways of reading something,
please take the most constructive and least offensive one.
I don't know very much about Indy - all I've done is look at some of
the web pages, download the .NET assembly and attempt (briefly, and
without any documentation) to use the NNTP client library. I have
absolutely no reason to doubt any of the claims made about the
excellence of the library and its importance in the Delphi world.
That said, I have grave reservations about the approach being taken
with regard to bringing it to .NET. Essentially, it's very obviously a
Delphi library in .NET clothing, as it were. There are three main
aspects to this:
1) The naming/organization conventions
2) The lack of XML documentation
3) The extra Borland-specific types (TStrings etc)
All of these make Indy unappealing as a .NET library - there is the
appearance that .NET is a second-class citizen as far as Indy is
concerned. I believe that the above will prevent Indy from being as
widely used and accepted as it might otherwise do - I believe people
will use "odds and sods" libraries for what they need rather than Indy,
if those libraries are written in a much more .NET-centric manner. This
is clearly a bad thing for Indy in terms of popular use (if you
particularly care about such things), reliability (the more people who
use a piece of open source software, the more reliable it's likely to
be) and community (the more users there are, the more they can help
each other).
To go into each of the drawbacks in more detail:
1) Naming Conventions
I'm probably a bit more gung-ho about naming than most people. I will
often think for quite a while just about the name of a class before
starting to code it, and if I later decide it's suboptimal, I will
spend significant effort changing it. (Refactoring capabilities in
Whidbey will help considerably here - naming has a much nicer feeling
in Eclipse, for instance.)
This is because I regard readability as pretty much *the* most
important thing in code. Code which is readable but broken is easily
fixed - code which works but is unreadable is hard to improve, and code
which is broken and unreadable is hard to fix in the first place.
Conventions aid readability, and one of the great things about modern
languages and platforms is that they tend to have a well-defined set of
conventions. Obviously they are only conventions, and no-one is forced
to use them, but life ends up being sweeter if everyone does. I've had
to read through some Java library code which used a mixture of normal
Java conventions and C naming conventions - it's really not pretty.
Things I normally take for granted (such as normal fields beginning
with a lower case letter, types beginning with an upper case letter
etc) are suddenly gone, and I feel at sea.
I have nothing against the Delphi convention in itself - I haven't
looked at it particularly carefully, but obviously various things leap
out at one (as indeed your FAQ points out). The problem isn't in the
convention itself, just that it's not the same as the .NET conventions.
Mixing the .NET conventions with the Java conventions would be just as
bad - it just makes life harder, and the code no longer looks
consistent.
2) XML documentation
I've been using Java for about 9 years, and .NET for about a year and a
half. I've really become used to code being documented in a
standardised way - preferrably every field, method, type, property etc.
The standardisation is important here, because it means that IDEs can
use the information. I can go for hours without consulting Javadoc
directly when coding in Eclipse. VS.NET isn't quite as good in terms of
displaying all the pertinent information, but it's still pretty good.
Using a library without appropriate documentation available in the IDE
feels like bumbling around with a blindfold on. Either I need to keep
swapping between the documentation and the IDE, or I have to do things
by trial and error, neither of which appeal. Even coding by trial and
error is harder than it might be, due to the naming convention
unfamiliar.
In short, I consider comprehensive XML documentation to be pretty much
a must for a .NET library to be taken seriously.
3) Borland-specific types
If I'm learning a new library, I fully expect to have to learn new
types which are directly related to the subject matter of the library.
I don't expect to have to learn a new string library (etc) at the same
time. I also don't want to have the baggage of those extra libraries
hanging around my application. I don't know how much of the 3M of the
Indy assembly is actually Indy as opposed to Borland, but I expect it's
a not inconsiderable amount. The CLR is memory hungry already, without
extra baggage which really belongs to another environment.
In short, while I would like to use code of the quality of Indy from
within .NET, I don't feel comfortable with using it while it's so
obviously not designed for .NET.
What can be done about this?
The obvious potential next step would be to rewrite the whole thing in
C#. (Or perhaps in Delphi, if there is a version of Delphi which
doesn't rely on Borland's own libraries, using the "old" Delphi
conventions etc.) While an obvious suggestion, I have no doubt
whatsoever that it's entirely impractical - that there's an awful lot
of code here, and that maintaining two versions would be very
difficult. I don't know whether the Indy project is a fan of unit
testing - if it is, that would make things much simpler indeed, but
still not *really* easy.
The next suggestion addresses the first two: start writing XML
documentation (which will take a *long* time, I understand) and work
out a way of converting from Delphi conventions to .NET conventions. We
talked in a previous thread about the difficulty of keeping
documentation in code, but I do believe it's vital for libraries (and
for applications, for the sake of the developers themselves).
Application user documentation is unsuitable for the code itself, but
documenting what every field and method does is good for everyone, as
far as I can see. The convention issue is a slightly tougher one,
because it requires something which can manipulate IL to change names
here there and everywhere. along with a rule engine to guide the
conversions (with suitable override capabilities where the engine gets
it wrong). This obvious affects the documentation as well.
I think it really depends on how serious the Indy team is about .NET.
If the idea is to be able to still support people who are/were Delphi
programmers who are already familiar with Indy and wish to use it in
..NET now they're developing there as well, that's fine, and you don't
need to implement any of the above.
If, however, you're seriously presenting Indy as a first class
networking library for .NET, it's currently a "miss" as far as I'm
concerned. If I need a networking library at the moment, I'll firstly
look for ones which are written specifically for .NET, complying with
its conventions and idioms, then look at how long it would take me to
write a library myself which does enough of what I need, and then I'll
look at Indy. There's no doubt that in some cases the result will be to
use Indy - but probably only until another network library comes up
which does that bit that I need in a more .NET-centric way. This is a
real shame, as I'm sure if I were a Delphi developer I'd embrace Indy
wholeheartedly.
All that being said, I certainly wish the Indy team well, whatever
direction they choose to take the project in. If that direction is one
which interests me further (e.g. either of the two work-heavy
suggestions above), I'll be more than happy to help however I can. I'm
sorry if this post has sounded mostly negative - it in not a reflection
of my feelings about the Indy project in general, or the developers.
It's *only* a reflection of how unfortunately far short Indy falls of
being a library I'd consider immediately when thinking about any
networking task. (Even "falling short" is inaccurate - it doesn't fall
short of a target so much as it jumps and hits an entirely different
and irrelevant (to me) target.)
Oh, and congratulations to anyone who managed to read this far. Have a
lollipop.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: I've thought long and hard about this post, and hopefully it won't
cause offence - wherever there are two ways of reading something,
Not at all.
1) Naming Conventions
An extra T does not break a library. Removing T's would break the Delphi
base quite badly by breaking ALL user code.
We could do a search and replace on build for VS, but this would make a
real hack of the docs. Sure its possible, but Im just not convinced that
people are goig to say "Damn, its got a T. Cant use it".
I have nothing against the Delphi convention in itself - I haven't
looked at it particularly carefully, but obviously various things leap
Its just like in C++ undef MFC the convention was to prefix classnames with
C. Some C# programmers still do it.
2) XML documentation
We think we have this one solved, but its going to be a few weeks to be
able to output the docs to this format.
3) Borland-specific types
If I'm learning a new library, I fully expect to have to learn new
types which are directly related to the subject matter of the library.
I don't expect to have to learn a new string library (etc) at the same
time. I also don't want to have the baggage of those extra libraries
A) We really only expose two that you will see.
B) Both have direct adaptors that you just "cast" and they are done.
Examples in the article.
We have considered ifdeffing in .net versions, but it makes spaghetti of
the code with IFDEFS. It is possible we could make the build process
somehow parse and modify but that looks like it would require some hefty
parsing.
hanging around my application. I don't know how much of the 3M of the
Indy assembly is actually Indy as opposed to Borland, but I expect it's
a not inconsiderable amount. The CLR is memory hungry already, without
extra baggage which really belongs to another environment.
The Delphi "environment" its not very memory hungry to use. Its just that
we have to staticly link in the RTL parts rigtht now and AFAIK in the .net
version it does not elinate unused code. However probably a good deal of
the 3M is Indy. Indy is HUGE.
The obvious potential next step would be to rewrite the whole thing in
C#. (Or perhaps in Delphi, if there is a version of Delphi which
No way - for several reasons.
1) Creating a fork. Who will maintain it?
2) Who will port it?
3) What about the existing user base? It is HUGE.
doesn't rely on Borland's own libraries, using the "old" Delphi
Fork problems.
conventions etc.) While an obvious suggestion, I have no doubt
whatsoever that it's entirely impractical - that there's an awful lot
of code here, and that maintaining two versions would be very
Exactly.
difficult. I don't know whether the Indy project is a fan of unit
testing - if it is, that would make things much simpler indeed, but
still not *really* easy.
VERY big:
http://www.indyproject.org/bubelen/
The next suggestion addresses the first two: start writing XML
documentation (which will take a *long* time, I understand) and work
Actually not that bad. Its just a matter of getting our existing docs to be
able to output this way.
out a way of converting from Delphi conventions to .NET conventions. We
talked in a previous thread about the difficulty of keeping
documentation in code, but I do believe it's vital for libraries (and
for applications, for the sake of the developers themselves).
Not in code. I stated briefly before:
1) Developers dont update it.
2) It interferes with the code by adding tons of noise.
3) The code editor is a code editor - it makes a horrible word processor
and then you have to manually edit tags and cross link, etc.
4) It pits the docs team against the dev team in the VCS.
If, however, you're seriously presenting Indy as a first class
networking library for .NET, it's currently a "miss" as far as I'm
concerned. If I need a networking library at the moment, I'll firstly
Since XML docs are not an issue anymore, I dont see that an extra T kills a
library.
Nor the convertors as they are just an extra few letters on certain
methods.
Both are possibly resolvable, but take time and Im not sure they are
critical.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Two other things I should mention. :)
1) There are no libraries as extensive as Indy. Most users end up hacking
their own protocols each time. Years ago this was how Delphi was too.
2) Its free. :)
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: 3) The extra Borland-specific types (TStrings etc)
Regarding this point, here is some sample code:
using System;
using System.IO;
using System.Text;
using Indy.Sockets.IdCLRStream;
using Indy.Sockets.IdHTTP;
namespace IntroHTTP
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
ASCIIEncoding LASCII = new ASCIIEncoding();
String LResult;
MemoryStream LStream = new MemoryStream();
TIdHTTP LHTTP = new TIdHTTP();
LHTTP.Get("http://www.atozed.com", new TIdCLRStream(LStream));
LResult = LASCII.GetString(LStream.ToArray());
LStream.Close();
Console.WriteLine(LResult);
Console.WriteLine("Press Enter");
Console.ReadLine();
}
}
}
It looks very .net to me. Considering how much monkeying it takes to get a
string from a stream in .net compared to native Delphi, I really cannot
image that this:
LHTTP.Get("http://www.atozed.com", new TIdCLRStream(LStream));
vs
LHTTP.Get("http://www.atozed.com", LStream);
Would make developers drop a library. Especially after things like:
LResult = LASCII.GetString(LStream.ToArray());
Which are pure ..net.
You can ignre the L,s etc. Thats not Indy, just my convention.
Aside from this the TId is the only "odd" thing. And its certainly not
completley foreign, or for that matter even a technical issue. A "TId" in
no way affects the technical aspects of the library.
So I return the questions. :)
1) Assume docs are solved.
2) TId - can be solved but Im not sure that it needs to. If you REALLY
think its that big of a issue, we're open to it. I certainly could have my
mind changed to (in time) alter the build process to modify the Indy files
on the fly during the build process for .net.
3) TIdCLRStream and TIdStringArray are the two adaptors you need.
Everything else is pretty much strings, etc... And you can see how easy
they are to use. You dont even need to mess with them. In fact they "Act"
like a cast.
There are no other places you would see "VCLisms" that I can think of.
Delphi is an amazingly flexible language and Borland did an incredible job
of mapping it to .net.
The only reason these two remain are because we have a single source issue.
They could be eliminated with ifdefs, but that creates a BIG maintainance
as well as initial issue as these two types are very very commonly used.
Also keep in mind that this release so far is just a "preview" and or test.
We ARE open to discussion and changes - but we do have an existing HUGE
user base. As for .net - this is exactly why we want to bring some .net
developers in.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: I've thought long and hard about this post, and hopefully it won't
cause offence - wherever there are two ways of reading something,
Not at all.
Goodo :)
1) Naming Conventions
An extra T does not break a library. Removing T's would break the Delphi
base quite badly by breaking ALL user code.
We could do a search and replace on build for VS, but this would make a
real hack of the docs. Sure its possible, but Im just not convinced that
people are goig to say "Damn, its got a T. Cant use it".
It's not just a T though, of course. It's a TId, an Id, an EId, a
TEvent etc. It certainly doesn't *break* a library, but when mixed with
the .NET conventions, it makes for far less readable code, IMO. Don't
forget that you're rather used to the conventions - I'm thinking about
people whose *only* exposure to the Delphi conventions is Indy.
I have nothing against the Delphi convention in itself - I haven't
looked at it particularly carefully, but obviously various things leap
Its just like in C++ undef MFC the convention was to prefix classnames with
C. Some C# programmers still do it.
Not if they're in my team they don't :)
Mixing conventions is just a really bad idea, IMO - for one thing the
conventions are a subliminal hints about which language you're using,
so you don't get confused in terms of the idioms to use etc.
2) XML documentation
We think we have this one solved, but its going to be a few weeks to be
able to output the docs to this format.
Excellent. That's a big step forward.
3) Borland-specific types
If I'm learning a new library, I fully expect to have to learn new
types which are directly related to the subject matter of the library.
I don't expect to have to learn a new string library (etc) at the same
time. I also don't want to have the baggage of those extra libraries
A) We really only expose two that you will see.
Unfortunately the other types are still public. Typing "b" then ctrl-
space in VS.NET is still going to suggest "Borland", and in the classes
where the developer has a "using Borland.Vcl.Classes" directive to make
working with TStrings easier, typing "t" then ctrl-space is going to
suggest loads of extra classes.
B) Both have direct adaptors that you just "cast" and they are done.
Examples in the article.
That's good. I hadn't seen that in the article.
We have considered ifdeffing in .net versions, but it makes spaghetti of
the code with IFDEFS. It is possible we could make the build process
somehow parse and modify but that looks like it would require some hefty
parsing.
Hmm... I'll have a think about any ways round that, after looking at it
a bit further. It might be possible to write a tool which put the cast
into the library (before return or on accepting a parameter) rather
than exposing it.
hanging around my application. I don't know how much of the 3M of the
Indy assembly is actually Indy as opposed to Borland, but I expect it's
a not inconsiderable amount. The CLR is memory hungry already, without
extra baggage which really belongs to another environment.
The Delphi "environment" its not very memory hungry to use. Its just that
we have to staticly link in the RTL parts rigtht now and AFAIK in the .net
version it does not elinate unused code. However probably a good deal of
the 3M is Indy. Indy is HUGE.
I'm sure Indy is big, but IL is generally pretty small :) For the sake
of interest, I'll look into this and come back with the results.
The obvious potential next step would be to rewrite the whole thing in
C#. (Or perhaps in Delphi, if there is a version of Delphi which
No way - for several reasons.
<snip>
difficult. I don't know whether the Indy project is a fan of unit
testing - if it is, that would make things much simpler indeed, but
still not *really* easy.
VERY big:
http://www.indyproject.org/bubelen/
Cool - not that it helps in this case, but good anyway :)
The next suggestion addresses the first two: start writing XML
documentation (which will take a *long* time, I understand) and work
Actually not that bad. Its just a matter of getting our existing docs to be
able to output this way.
Good news.
out a way of converting from Delphi conventions to .NET conventions. We
talked in a previous thread about the difficulty of keeping
documentation in code, but I do believe it's vital for libraries (and
for applications, for the sake of the developers themselves).
Not in code. I stated briefly before:
1) Developers dont update it.
Then they should be encouraged to, IMO. If a developer doesn't update
the docs, how is anyone else supposed to? Isn't it just as quick to
write a short note in the docs as to what's changed as it is to write
the same note to someone in the docs team so that they can do it at a
later date?
2) It interferes with the code by adding tons of noise.
Code folding takes care of this where it's an issue, I find. Indeed,
unless I'm editing a method, I find it's often a good idea to *only*
have the method comment up rather than the method body. If the method
comment doesn't cover everything you need to know, then the comment
should be fixed.
3) The code editor is a code editor - it makes a horrible word processor
and then you have to manually edit tags and cross link, etc.
I don't find that a problem, myself. I don't tend to use that many
cross-links that aren't automatically generated, admittedly, but I
still don't find it a problem. Type/member/method level docs should
rarely be that lengthy, IMO.
4) It pits the docs team against the dev team in the VCS.
The dev team should *be* the docs team when it comes to documenting
methods etc, IMO. Or at least, they should be the principle docs team,
with there being others putting a bit of spit and polish on if a
developer isn't a particularly good natural language communicator, for
example. If, however, you're seriously presenting Indy as a first class
networking library for .NET, it's currently a "miss" as far as I'm
concerned. If I need a networking library at the moment, I'll firstly
Since XML docs are not an issue anymore, I dont see that an extra T kills a
library.
Nor the convertors as they are just an extra few letters on certain
methods.
Both are possibly resolvable, but take time and Im not sure they are
critical.
As I said before, I'm sure they aren't a problem at all for you, as
you're already familiar with the convention, but I'm speaking for
myself - and I they lead to a significant reduction in readability as
far as I'm concerned.
When the XML documentation is available I'll give it another try, but
with readability being of huge importance to me, the conventions are
the main thing for me. They're also likely to be the first thing to put
off other people who are quickly looking at various libraries - if one
of them looks out of place (as conventions from another environment
do), they're likely to move on without seeing all the good things about
Indy. If you don't mind people like them (or me) bypassing Indy, that's
absolutely fine - but I'd have felt bad about not giving you this
feedback. "Critical" depends on what the goals of Indy are.
If you ever do decide you'd like to seriously consider something to
convert the naming conventions and possibly Delphi type replacement
(without your Delphi code having to change), let me know and I'll look
into it. I've looked into the PE and IL file formats a bit, and
wouldn't mind revisiting that work and trying to write a tool which let
you really manipulate assemblies in the kind of ways I've been talking
about. It wouldn't be a small task, but it would have uses way beyond
Indy.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in
news:Xn******************@127.0.0.1: What? Its only 2:49am on this side of the planet. ;)
I see now that we are on the same side of the planet. Im just in a colder
locale to the north and east quite a ways... at least for 2 more weeks till I
go to my normal much warmer winter locale to the south east a ways from you.
:)
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: By modifying the signature and method body directly, and putting the
conversion in the method.
I really like this idea. :)
I've had two more thoughts on this:
1) It might be easiest temporarily to work with the IL assembly code
itself - i.e. run ildasm on the assembly, run something which changes
the IL assembly code, then ilasm to reassemble it. That would allow us
to try a few different options relatively easily, I think.
2) Can you specify implicit conversion operators in Delphi? I don't
generally like them, but if there were implicit conversion operators
to/from the adaptor classes, that might give a "pretty good" solution
in one fell swoop. The developer would still see TIdStringArray in
signatures, but could basically ignore it. This could be a cheap way of
getting *almost* all the way there.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in news:MPG.1a7d67d96235bc64989f93
@msnews.microsoft.com: 1) It might be easiest temporarily to work with the IL assembly code
itself - i.e. run ildasm on the assembly, run something which changes
the IL assembly code, then ilasm to reassemble it. That would allow us
to try a few different options relatively easily, I think.
Yes. Thats a very good idea.
2) Can you specify implicit conversion operators in Delphi? I don't
generally like them, but if there were implicit conversion operators
to/from the adaptor classes, that might give a "pretty good" solution
in one fell swoop. The developer would still see TIdStringArray in
signatures, but could basically ignore it. This could be a cheap way of
getting *almost* all the way there.
Im not quite following. Can you explain a bit?
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Socket question for ya. Want a udp server to listen and reply on port n.
Want one thread as just the listener and one thread as just the sender
sharing the socket. The doco says updclient and socket are not thread safe,
however others say that doing a send on one a receive on another is ok -
just don't have two threads both doing sends or receives on the same socket.
I tried using seperate sockets all together and using IPAddressReuse.
However that is a problem, because the sender sometimes gets the receivers
data, and cause it never calls Receive, the dgram is lost. TIA
--
William Stacey, MVP
"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn******************@127.0.0.1... A few of you may recognize me from the recent posts I have made about Indy
<http://www.indyproject.org/indy.html>
Those of you coming to .net from the Delphi world know truly how unique
and "huge" Indy is both as a project, in support, development, and use. But
Indy is new to the .net world.
Indy is a HUGE library implementing over 120 internet protocols and
standards and comes with complete source. Its an open source project, but
not your typical abandonware type. It has a development team of
approximately 40 people who are very active, a dedicated documentation
team, a dedicated demo team, a support team, commercial support options,
and even a book.
Its hard to simply take someones word for this - especially when the word
is from someone who is not well known in the .net world (yet! :) ).
<http://www.hower.org/Chad/Bio.html>
I currently speak at 6-8 conferences around the world each year as well as
regularly write for Delphi magazines.
But Indy is huge - and even with System.Net.Sockets Indy still has a LOT
to offer. Its like comparing a kitchen knife with Swiss Army's top model
knife.
For some basics you can see:
<http://www.atozed.com/indy/Texts/WhyIndy.iwp>
The team obviously is heavily Delphi based. Many of us are doing C# work
as well because Delphi 8 just arrived and many of us needed .net earlier. And
many of us still cross over back and forth between VS and Delphi.
What we need is some VS users - in this case C# users to join a new team
we are forming. We have not named this team yet, but this team would help us
move foward into the VS / .net (other IDEs) world. Roles will be mixed -
support, input, direction, docs, writing demos, and more. Dont worry - you
dont have to do it all. Thats what a team is about - but everyone can
contribute what they are able too.
Not a guru? It doesnt matter. While we welcome and would love to have some
MVPs and MSCE's on board, we are looking for average Joe's, corporate
developers, students, hobbyists and even the newbie!
Rewards? Well Indy is free. But its a very rewarding experience, as well
as a chance to learn, meet new people, experience new code, and be part of a
team. Best of all to forward a very cool and already successful open
source project!
Previously a Delphi or a current cross over user? If so - you can reply
and lend some credibility to my message for those who have no clue who I am.
In the Delphi world I am fairly well known - but I am a newcomer and do not
have much name recogntion here, and neither does Indy yet.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: With C++ in MFC at least classes were C+Classname. C++ does allow
managed code. Assuming that somone has "ported" existing code and its
single source - have they removed all their C's from the code?
They should have done, IMO, yes - especially if they care about
consistency with other .NET libraries.
But lets assume they are single source, and still have to support native MFC.
ie, its one source code base.
Then I would attempt to do the same kind of name changing I'm
suggesting here.
Would people hold the same standard as they would to Delphi or say "Well its
MS code, its ok".
I don't know about anyone else, but *I* would hold it to the same
standard. MS gets no special dispensation from me.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: Jon Skeet [C# MVP] <sk***@pobox.com> wrote in news:MPG.1a7d67d96235bc64989f93
@msnews.microsoft.com: 1) It might be easiest temporarily to work with the IL assembly code
itself - i.e. run ildasm on the assembly, run something which changes
the IL assembly code, then ilasm to reassemble it. That would allow us
to try a few different options relatively easily, I think.
Yes. Thats a very good idea.
Much less work, too :)
However, thinking about it, changing the method signatures will break
anything internal that calls the method. Adding overloads avoids that
problem - but doesn't help for return values. This is what comes of
designing solutions late on a Saturday night :) (That doesn't mean the
idea doesn't have merit, just that it obviously needs more thought.) 2) Can you specify implicit conversion operators in Delphi? I don't
generally like them, but if there were implicit conversion operators
to/from the adaptor classes, that might give a "pretty good" solution
in one fell swoop. The developer would still see TIdStringArray in
signatures, but could basically ignore it. This could be a cheap way of
getting *almost* all the way there.
Im not quite following. Can you explain a bit?
Sure. In C# you can specify implicit or explicit conversions between
types. For instance, here's a program which demonstrates a type (name)
which can be implicitly converted to and from a string:
using System;
public class Name
{
string value;
public Name(string value)
{
this.value = value;
}
public static implicit operator string (Name name)
{
return name.value;
}
public static implicit operator Name (string value)
{
return new Name (value);
}
}
public class Test
{
static void Main()
{
// Implicit conversion from string to Name
Name x = "Jon";
// Implicit conversion from Name to string
string y = x;
}
}
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"William Stacey" <st***********@mvps.org> wrote in
news:eT**************@TK2MSFTNGP11.phx.gbl: Socket question for ya. Want a udp server to listen and reply on port
Probably should have started this as a new thread, but I'll reply here so you
see it.
n. Want one thread as just the listener and one thread as just the
sender sharing the socket. The doco says updclient and socket are not
thread safe, however others say that doing a send on one a receive on
another is ok - just don't have two threads both doing sends or receives
On the socket level it is perfectly acceptable. But who knows what the .Net
SDK does besides the socket calls. Thats one thing I really miss in .net vs
VCL is source. In VCL we always had source to see what was going on, often
even the intent.
You are probably safe to do it - assuming the .net class does not share some
variables between read and write routines. The could be sharing some kind of
event handle if its resouce intensive. So really its a pot shot.
But the socket itself definiteliy supports it, and I can tell you that Indy
for sure supports it. Want to use the Indy UDP classes? :)
on the same socket. I tried using seperate sockets all together and
using IPAddressReuse. However that is a problem, because the sender
sometimes gets the receivers data, and cause it never calls Receive, the
dgram is lost. TIA
Yes. Thats exactly what happens when you force two UDPs on the same port. You
dont want that in your case.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: However, thinking about it, changing the method signatures will break
anything internal that calls the method. Adding overloads avoids that
Yes that would be a problem. The protocol methods are normaly endpoints and
are not called from internally, but many middle classes have methods that are
used by users.
problem - but doesn't help for return values. This is what comes of
designing solutions late on a Saturday night :) (That doesn't mean the
Indy typically uses var (by ref) arguments when its not a simple type. But
there are a few instances of TStrings as a result IIRC. We could maybe map
them to ones that use by ref calls and keep the existing ones as well? Im not quite following. Can you explain a bit?
Sure. In C# you can specify implicit or explicit conversions between
types. For instance, here's a program which demonstrates a type (name)
which can be implicitly converted to and from a string:
Delphi only supports thes in Delphi.net (AFAIK), not previous versions.
If it did - how would this help our situation though? And remember - these
are not just valued classes. They are actual classes with methods that Indy
uses, so Im not sure that this is workable either.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Thanks Chad for confirming that for me. I suspected the same. I will try
your library. Cheers!
--
William Stacey, MVP
"Chad Z. Hower aka Kudzu" <cp**@hower.org> wrote in message
news:Xn******************@127.0.0.1... "William Stacey" <st***********@mvps.org> wrote in
news:eT**************@TK2MSFTNGP11.phx.gbl: Socket question for ya. Want a udp server to listen and reply on port
Probably should have started this as a new thread, but I'll reply here so
you see it.
n. Want one thread as just the listener and one thread as just the
sender sharing the socket. The doco says updclient and socket are not
thread safe, however others say that doing a send on one a receive on
another is ok - just don't have two threads both doing sends or receives
On the socket level it is perfectly acceptable. But who knows what the
..Net SDK does besides the socket calls. Thats one thing I really miss in .net
vs VCL is source. In VCL we always had source to see what was going on, often
even the intent.
You are probably safe to do it - assuming the .net class does not share
some variables between read and write routines. The could be sharing some kind
of event handle if its resouce intensive. So really its a pot shot.
But the socket itself definiteliy supports it, and I can tell you that
Indy for sure supports it. Want to use the Indy UDP classes? :)
on the same socket. I tried using seperate sockets all together and
using IPAddressReuse. However that is a problem, because the sender
sometimes gets the receivers data, and cause it never calls Receive, the
dgram is lost. TIA
Yes. Thats exactly what happens when you force two UDPs on the same port.
You dont want that in your case.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: However, thinking about it, changing the method signatures will break
anything internal that calls the method. Adding overloads avoids that
Yes that would be a problem. The protocol methods are normaly endpoints and
are not called from internally, but many middle classes have methods that are
used by users.
Right. problem - but doesn't help for return values. This is what comes of
designing solutions late on a Saturday night :) (That doesn't mean the
Indy typically uses var (by ref) arguments when its not a simple type. But
there are a few instances of TStrings as a result IIRC. We could maybe map
them to ones that use by ref calls and keep the existing ones as well?
Eek - I hadn't realised Indy used a lot of pass-by-reference. I'm
personally pretty averse to it, and again, it's not "the normal .NET
way of doing things". Again, this is no criticism of Indy and its
history, just another barrier to adoption. It needn't be a fatal one,
but it is one nonetheless. Im not quite following. Can you explain a bit?
Sure. In C# you can specify implicit or explicit conversions between
types. For instance, here's a program which demonstrates a type (name)
which can be implicitly converted to and from a string:
Delphi only supports thes in Delphi.net (AFAIK), not previous versions.
If it did - how would this help our situation though? And remember - these
are not just valued classes. They are actual classes with methods that Indy
uses, so Im not sure that this is workable either.
I think you were missing my point - or I'm missing yours. The extra
classes (TIdStringArray or TStrings, for instance - to be honest, I've
somewhat lost the plot as to what is what could still appear in the
interface, but wouldn't need to be seen at all in the .NET developer's
code. They could pass a string array, and a conversion could be
performed (in exactly the way you show in your examples) to convert to
the relevant type.
Users would still need to recognise TIdStringArray or TStrings or
whatever, and realise that they can treat it as a string[], but it
would be better than the conversions occurring in their own code - in
my view, anyway.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"William Stacey" <st***********@mvps.org> wrote in news:uB89BK74DHA.2656
@TK2MSFTNGP11.phx.gbl: Thanks Chad for confirming that for me. I suspected the same. I will try
your library. Cheers!
The docs arent converted yet so you'll have to use the VCL ones, which arent
up todate for Indy 10 yet (Soon!). So really just ask away here or on the
Indy NGs and we'll be glad to help you with code and more. :)
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: Indy typically uses var (by ref) arguments when its not a simple type.
But there are a few instances of TStrings as a result IIRC. We could
maybe map them to ones that use by ref calls and keep the existing ones
as well?
Eek - I hadn't realised Indy used a lot of pass-by-reference. I'm
Double eek. Im not sure why I wrote that - its completley long. Wayyyy too
many times this week I've gone to bed at 6am because of a pending deadline.
It does NOT pass by reference. What it does is accept existing object
instances to operate on, rather than create the instances itself and return
them as results. There are only a few cases it creates instances for you.
For example:
HTTP.Get(URL, <stream>);
Rather than:
stream = HTTP.Get(URL);
In the first form the user must create the stream and pass it in. This is
good because there are many kinds of streams. But for string[] Indy usually
works this way too, in which there is only one type of string[].
Plain strings are different, they are returned as results:
s = HTTP.Get(URL);
I think you were missing my point - or I'm missing yours. The extra
classes (TIdStringArray or TStrings, for instance - to be honest, I've
somewhat lost the plot as to what is what could still appear in the
interface, but wouldn't need to be seen at all in the .NET developer's
code. They could pass a string array, and a conversion could be
performed (in exactly the way you show in your examples) to convert to
the relevant type.
Thats just it - They DO pass an array. I see what you are saying, it is
possible with the strings[] vs TStrings, but not the TStream. TStrings has
a value - a TStream does not. And since streams are abstract I cannot see
any way to even try to convert a "value".
So currently for Indy you do:
MyDotNetStream = new StreamWhatever();
HTTP.Get("http://www.atozed.com", new CLSStream(MyDotNetStream));
Use MyDotNetStream here.
Your change would make it look like:
MyVCLStream = new TMemoryStream();
HTTP.Get("http://www.atozed.com", new CLSStream(MyDotNetStream));
MyDotNetStream = new StreamWhatever();
MyDotNetStream = MyVCLStream;
Use MyDotNetStream here.
To me the first (And existing one) is cleaner. And the second form would
only possible for strings[].
The ONLY impact on .net users is they have to use the adaptor when calling
- otherwise they work directly with .net types. They dont touch VCL types.
Users would still need to recognise TIdStringArray or TStrings or
whatever, and realise that they can treat it as a string[], but it
Wrong - they dont use our string array - they use the .net one.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: Indy typically uses var (by ref) arguments when its not a simple type.
But there are a few instances of TStrings as a result IIRC. We could
maybe map them to ones that use by ref calls and keep the existing ones
as well?
Eek - I hadn't realised Indy used a lot of pass-by-reference. I'm
Double eek. Im not sure why I wrote that - its completley long. Wayyyy too
many times this week I've gone to bed at 6am because of a pending deadline.
Fair enough :)
It does NOT pass by reference. What it does is accept existing object
instances to operate on, rather than create the instances itself and return
them as results. There are only a few cases it creates instances for you.
Right. I personally find that's rarely a useful pattern, but I can
adapt to it, I'm sure. It's certainly less of a problem than if pass by
reference were used all over the place :)
For example:
HTTP.Get(URL, <stream>);
Rather than:
stream = HTTP.Get(URL);
In the first form the user must create the stream and pass it in. This is
good because there are many kinds of streams. But for string[] Indy usually
works this way too, in which there is only one type of string[].
But how does the caller know how large to make the array to start with,
out of interest?
Plain strings are different, they are returned as results:
s = HTTP.Get(URL);
Good.
I think you were missing my point - or I'm missing yours. The extra
classes (TIdStringArray or TStrings, for instance - to be honest, I've
somewhat lost the plot as to what is what could still appear in the
interface, but wouldn't need to be seen at all in the .NET developer's
code. They could pass a string array, and a conversion could be
performed (in exactly the way you show in your examples) to convert to
the relevant type.
Thats just it - They DO pass an array. I see what you are saying, it is
possible with the strings[] vs TStrings, but not the TStream. TStrings has
a value - a TStream does not. And since streams are abstract I cannot see
any way to even try to convert a "value".
But your article gives an example of exactly that:
<quote>
To use a FCL stream simply use the following syntax:
LHTTP.Get(new TIdCLRStream(<FCL Stream Instance>); (C#)
</quote>
So currently for Indy you do:
MyDotNetStream = new StreamWhatever();
HTTP.Get("http://www.atozed.com", new CLSStream(MyDotNetStream));
Use MyDotNetStream here.
Your change would make it look like:
MyVCLStream = new TMemoryStream();
HTTP.Get("http://www.atozed.com", new CLSStream(MyDotNetStream));
MyDotNetStream = new StreamWhatever();
MyDotNetStream = MyVCLStream;
Use MyDotNetStream here.
No - my change would make it look like:
Stream myStream = new MemoryStream();
HTTP.Get("http://www.atozed.com", myStream);
Use mystream here
To me the first (And existing one) is cleaner. And the second form would
only possible for strings[].
The ONLY impact on .net users is they have to use the adaptor when calling
- otherwise they work directly with .net types. They dont touch VCL types.
But with my version they don't even need to have *any* adaptor code in
their code. They only need to know that when they see an adaptor type
in the signature, they can just use the .NET type instead, and the
conversion will be performed automatically. Users would still need to recognise TIdStringArray or TStrings or
whatever, and realise that they can treat it as a string[], but it
Wrong - they dont use our string array - they use the .net one.
By "use" I mean "include some code which mentions it" - won't I have to
say:
string[] myStringArray = {... whatever ...};
something.CallSomeMethod (new TIdStringArray (myStringArray));
With the implicit conversions, I could just say:
string[] myStringArray = {... whatever ...};
something.CallSomeMethod (myStringArray);
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: Right. I personally find that's rarely a useful pattern, but I can
adapt to it, I'm sure. It's certainly less of a problem than if pass by
reference were used all over the place :)
But it is very useful - how can you create a stream if you dont know what
kind of stream the user wants, or even what parameters the stream needs to
be created? or if the user wants you to write in a stream that already has
data?
..Net Im sure has many such examples. Many constructers relating to stream
accept other stream type objects. Same thing.
But how does the caller know how large to make the array to start with,
out of interest?
They dont. They just create it, Indy sizes and fills it.
You could even do:
HTTP.Get(URL, new new StringAdaptor(new string array)))
But then of course you would have no reference to it to read it. :)
Assuming Get took strings, which it doesnt it takes streams. Most users use
the string variant which returns as a function result. The stream version
is for binary files or if you want to direct it to a stream target
directly.
But your article gives an example of exactly that:
<quote>
To use a FCL stream simply use the following syntax:
LHTTP.Get(new TIdCLRStream(<FCL Stream Instance>); (C#)
</quote>
Yes, that exactly the same as the code I posted. The FCL stream instance
was MyDotNetStream which is already created by you.
TIdCLRStream is a class of ours that remaps TStreams methods to call the
matching methods in the .net STream. So we operate directly on your stream
internally, via a translator. Same for strings[].
No - my change would make it look like:
Stream myStream = new MemoryStream();
HTTP.Get("http://www.atozed.com", myStream);
Use mystream here
Your IL based change would yes. But not your type convertor suggestion to
which I was referring in this case.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: Right. I personally find that's rarely a useful pattern, but I can
adapt to it, I'm sure. It's certainly less of a problem than if pass by
reference were used all over the place :)
But it is very useful - how can you create a stream if you dont know what
kind of stream the user wants, or even what parameters the stream needs to
be created? or if the user wants you to write in a stream that already has
data?
You provide whichever version of a stream you want to, and clients can
read from it, treating it just as a stream.
.Net Im sure has many such examples. Many constructers relating to stream
accept other stream type objects. Same thing.
But those are for creating new objects which effectively wrap a stream
- and carry the same "direction". You're using stream as a sort of
bidirectional thing - you write to it and then the client reads from
it. That seems odd to me.
However, I don't want to get bogged down by this - I'm certainly not
asking for a change here.
But how does the caller know how large to make the array to start with,
out of interest?
They dont. They just create it, Indy sizes and fills it.
Ah. That's a different matter then, and not well explained in your
article - I think an example is really called for on the page.
You could even do:
HTTP.Get(URL, new new StringAdaptor(new string array)))
But then of course you would have no reference to it to read it. :)
But if you already *have* a string array and provide a new
StringAdaptor, it won't be able to resize that original array...
But your article gives an example of exactly that:
<quote>
To use a FCL stream simply use the following syntax:
LHTTP.Get(new TIdCLRStream(<FCL Stream Instance>); (C#)
</quote>
Yes, that exactly the same as the code I posted. The FCL stream instance
was MyDotNetStream which is already created by you.
Yes indeed. I think we've got our wires seriously crossed here.
TIdCLRStream is a class of ours that remaps TStreams methods to call the
matching methods in the .net STream. So we operate directly on your stream
internally, via a translator. Same for strings[].
Except it's *not* the same for strings, because you can't resize an
array in .NET, which it sounds like you need to for your string array
adaptor. No - my change would make it look like:
Stream myStream = new MemoryStream();
HTTP.Get("http://www.atozed.com", myStream);
Use mystream here
Your IL based change would yes. But not your type convertor suggestion to
which I was referring in this case.
No, my type convertor version would cover that as well. Here's a
complete sample program in C# to show what I mean. If the .NET part of
Delphi can provide implicit conversions, I don't see why exactly the
same shouldn't be accomplished for Indy. You'd need to use an IFDEF for
the implicit conversions, but only on the adaptors, which I don't
expect would be too arduous.
using System;
using System.IO;
// Analogous to TIdCLRStream, I *think*!
public class StreamAdaptor
{
Stream baseStream;
public StreamAdaptor(Stream baseStream)
{
this.baseStream = baseStream;
}
public static implicit operator Stream (StreamAdaptor adaptor)
{
return adaptor.baseStream;
}
public static implicit operator StreamAdaptor (Stream baseStream)
{
return new StreamAdaptor (baseStream);
}
public void Write (byte[] bytes)
{
// Presumably in your real adaptor, you'd be doing more
// interesting stuff, I don't know
baseStream.Write(bytes, 0, bytes.Length);
baseStream.Flush();
}
}
// Analogous to an HTTP client class or whatever
public class SampleClient
{
public void Write5Bytes(StreamAdaptor adaptor)
{
adaptor.Write (new byte[] {0, 1, 2, 3, 4});
}
}
public class Test
{
static void Main()
{
MemoryStream ms = new MemoryStream();
SampleClient sample = new SampleClient();
// Observe the miracles of implicit conversion...
sample.Write5Bytes(ms);
Console.WriteLine (ms.Length);
}
}
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote: Your IL based change would yes. But not your type convertor suggestion to
which I was referring in this case.
No, my type convertor version would cover that as well. Here's a
complete sample program in C# to show what I mean. If the .NET part of
Delphi can provide implicit conversions, I don't see why exactly the
same shouldn't be accomplished for Indy. You'd need to use an IFDEF for
the implicit conversions, but only on the adaptors, which I don't
expect would be too arduous.
<snip>
Having just looked into this further, am I right in saying that
actually the situation is more like this:
1) There's a class TStream which is used in the client interface
2) There's a subclass of TStream, TIdCLRStream, which can be used
with .NET streams
?
If so, then that indeed wouldn't work - the conversion is only applied
when there's a conversion between the type in the method signature and
the desired type.
However, if TStream is only ever passed *in* to methods, the thing to
do is then move the conversion to TStream (with the conversion creating
an instance of TIdCLRStream):
using System;
using System.IO;
public abstract class TStream
{
public abstract void Write(byte[] bytes);
public static implicit operator TStream (Stream baseStream)
{
return new StreamAdaptor (baseStream);
}
}
// Analogous to TIdCLRStream, I *think*!
public class StreamAdaptor : TStream
{
Stream baseStream;
public StreamAdaptor(Stream baseStream)
{
this.baseStream = baseStream;
}
public override void Write (byte[] bytes)
{
// Presumably in your real adaptor, you'd be doing more
// interesting stuff, I don't know
baseStream.Write(bytes, 0, bytes.Length);
baseStream.Flush();
}
}
// Analogous to an HTTP client class or whatever
public class SampleClient
{
public void Write5Bytes(TStream stream)
{
stream.Write (new byte[] {0, 1, 2, 3, 4});
}
}
public class Test
{
static void Main()
{
MemoryStream ms = new MemoryStream();
SampleClient sample = new SampleClient();
// Observe the miracles of implicit conversion...
sample.Write5Bytes(ms);
Console.WriteLine (ms.Length);
}
}
That's fine so long as you're able to modify TStream, of course... but
it looks like TStream is part of the VCL and thus presumably can't be
changed. Shame :(
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: You provide whichever version of a stream you want to, and clients can
read from it, treating it just as a stream.
Then you have to create a method for every kind of stream.. Unless .net
works differently which I suspect it does. But lets say it applies to some
other polymorphic type class.
But those are for creating new objects which effectively wrap a stream
- and carry the same "direction". You're using stream as a sort of
bidirectional thing - you write to it and then the client reads from
it. That seems odd to me.
No - your missing it actually. :)
The client does NOT read back from the stream. In Delphi it would look
something like this:
LStream := TFileStream.Create('c:\test.html', fmCreate); try
HTTP.Get('http://www.atozed.com/', LStream);
finally LStream.Free; end;
We dont reread from the stream, we inialize it to just go wherever it is we
want. Stream may not be the exact class that the covnertor should map to in
..net. The example I had did reread from the streamm, but that was just demo
code.
The above by allowing an existing TStream to be passed in allows writing an
existing stream too:
LStream := TFileStream.Create('c:\test.html', fmOpenWrite); try
LStream.Position := LStream.Size;
HTTP.Get('http://www.atozed.com/', LStream);
finally LStream.Free; end;
I can also pass TStringStream (Kind of like a stringbuilder, but not quite
its not its direct companion or intended to be), TMemoryStream, TDataField
Stream, and soon ....
They dont. They just create it, Indy sizes and fills it.
Ah. That's a different matter then, and not well explained in your
article - I think an example is really called for on the page.
I'll make an update soon, Im working on the class name changes now. Its
what I inteded to convey.
HTTP.Get(URL, new new StringAdaptor(new string array)))
But then of course you would have no reference to it to read it. :)
But if you already *have* a string array and provide a new
StringAdaptor, it won't be able to resize that original array...
Why not? The string adaptor is just a polymorphic descendant of the VCL
TStrings abstract interface that maps our interface onto storage in a
strings[]. That is we operate directly on the strings[].
Again - there may be more suitable adaptors. TStrings is kind of like a C++
vector, its not really an array. Is there a better .net concept to map it
to?
TIdCLRStream is a class of ours that remaps TStreams methods to call
the matching methods in the .net STream. So we operate directly on your
stream internally, via a translator. Same for strings[].
Except it's *not* the same for strings, because you can't resize an
array in .NET, which it sounds like you need to for your string array
adaptor.
Yes we do need to resize. Hmm, I could swear we are resizing it
somehow..... Delphi arrays can be resized, and they map in Delphi.net to
strings[]... so?
There are also other options:
1) Internally we can use a TStringsList (A storage implemented descendant)
and then "commit" to a strings[].
2) Map to some other .net class.
complete sample program in C# to show what I mean. If the .NET part of
Delphi can provide implicit conversions, I don't see why exactly the
same shouldn't be accomplished for Indy. You'd need to use an IFDEF for
the implicit conversions, but only on the adaptors, which I don't
expect would be too arduous.
Yes, seeing your code below would work. Except - TStream is a defined non
modifiable abstract class.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: 1) There's a class TStream which is used in the client interface
Yes.
2) There's a subclass of TStream, TIdCLRStream, which can be used
with .NET streams
Yes.
However, if TStream is only ever passed *in* to methods, the thing to
At least in most cases. Off hand I cannot think of cases its passed outward.
That's fine so long as you're able to modify TStream, of course... but
Which we cannot - or maybe we can. Let me explain a bit further...
The VCL goes back many many years. Roots are farther back than Delphi in TP,
but really the VCL as we know it became public in early 1995. And code that
worked in 1995 works today, and code that works today with a little effort
(not much in most cases) runs back on Delphi 1. Quite an achievement.
But Delphi has also gained new features. Interfaces (About 1998) and many
other things. But since things like TStream were created in 1994 (Beta, was
released in 1995) before many of the newer features, the core VCL is still
using just those parts. Unless you want to break everyones code you cannot
just go in and change certain things. Sure the VCL has taken advantage in
adding newer parts using interfaces, overloads, and other parts, but TStream
is original and well established.
BUT - In Delphi 8 there is a concept called a class helper. I can use an
"auxillary" class to add to an existing middle class. Delphi uses this to add
TComponent "on top" of the .net Component and still have all the VCL classes
see your Component as our TComponent...
I'll have to look into the class helpers, but we migth be able to add the
implicit conversion this way. Thanks for all you thought on this, this might
make it work. But I have to do the class aliasing and docs first - so this is
at least a week away. :)
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: You provide whichever version of a stream you want to, and clients can
read from it, treating it just as a stream.
Then you have to create a method for every kind of stream.. Unless .net
works differently which I suspect it does. But lets say it applies to some
other polymorphic type class.
Yes, it sounds like Delphi's idea of a stream isn't the same as .NETs.
If I have a method which returns a stream, I don't need to care which
type of stream it is - I can just read from it.
But those are for creating new objects which effectively wrap a stream
- and carry the same "direction". You're using stream as a sort of
bidirectional thing - you write to it and then the client reads from
it. That seems odd to me.
No - your missing it actually. :)
The client does NOT read back from the stream. In Delphi it would look
something like this:
LStream := TFileStream.Create('c:\test.html', fmCreate); try
HTTP.Get('http://www.atozed.com/', LStream);
finally LStream.Free; end;
We dont reread from the stream, we inialize it to just go wherever it is we
want. Stream may not be the exact class that the covnertor should map to in
.net. The example I had did reread from the streamm, but that was just demo
code.
Ah, right. Okay, it makes a bit more sense now - and the above would be
fine in .NET too. When you'd talked about it being much easier to
convert a stream to text in Delphi, the example you gave was a pretty
tortuous one where I'd rarely design an interface in that way.
The above by allowing an existing TStream to be passed in allows writing an
existing stream too:
LStream := TFileStream.Create('c:\test.html', fmOpenWrite); try
LStream.Position := LStream.Size;
HTTP.Get('http://www.atozed.com/', LStream);
finally LStream.Free; end;
I can also pass TStringStream (Kind of like a stringbuilder, but not quite
its not its direct companion or intended to be), TMemoryStream, TDataField
Stream, and soon ....
Right.
They dont. They just create it, Indy sizes and fills it.
Ah. That's a different matter then, and not well explained in your
article - I think an example is really called for on the page.
I'll make an update soon, Im working on the class name changes now. Its
what I inteded to convey.
Okay. While you're at the updating business, could you change it to not
create an instance of ASCIIEncoding? Using the static Encoding.ASCII
property is much neater, IMO :)
HTTP.Get(URL, new new StringAdaptor(new string array)))
But then of course you would have no reference to it to read it. :)
But if you already *have* a string array and provide a new
StringAdaptor, it won't be able to resize that original array...
Why not? The string adaptor is just a polymorphic descendant of the VCL
TStrings abstract interface that maps our interface onto storage in a
strings[]. That is we operate directly on the strings[].
In .NET, arrays are a fixed size. You can't resize them. Whereas with
the stream adaptor you can just pass in an existing stream to the
constructor, and use the same stream afterwards to read from, with a
string array you'd need to fetch the potentially new string array back
afterwards:
string[] myStringArray = ...;
TIdStringArray foo = new TIdStringArray(myStringArray);
// Do something with foo, whatever...
// then...
myStringArray = foo.GetStringArray(); // Or however you convert back
Again - there may be more suitable adaptors. TStrings is kind of like a C++
vector, its not really an array. Is there a better .net concept to map it
to?
StringCollection, probably.
TIdCLRStream is a class of ours that remaps TStreams methods to call
the matching methods in the .net STream. So we operate directly on your
stream internally, via a translator. Same for strings[].
Except it's *not* the same for strings, because you can't resize an
array in .NET, which it sounds like you need to for your string array
adaptor.
Yes we do need to resize. Hmm, I could swear we are resizing it
somehow..... Delphi arrays can be resized, and they map in Delphi.net to
strings[]... so?
That sounds very odd, basically. They can't map very well...
There are also other options:
1) Internally we can use a TStringsList (A storage implemented descendant)
and then "commit" to a strings[].
2) Map to some other .net class.
It does sound like StringCollection is the way to go here. complete sample program in C# to show what I mean. If the .NET part of
Delphi can provide implicit conversions, I don't see why exactly the
same shouldn't be accomplished for Indy. You'd need to use an IFDEF for
the implicit conversions, but only on the adaptors, which I don't
expect would be too arduous.
Yes, seeing your code below would work. Except - TStream is a defined non
modifiable abstract class.
Damn :(
I presume it would be against the Borland licence to modify the runtime
library (.NET version) to add the extra implicit conversions?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: I'll have to look into the class helpers, but we migth be able to add the
implicit conversion this way. Thanks for all you thought on this, this might
make it work. But I have to do the class aliasing and docs first - so this is
at least a week away. :)
No problem :)
Would there be a better newsgroup to discuss this in, by the way? It's
not very closely related to C#. I see there's a dotnet Indy newsgroup
on the Atozed server (which I eventually found - I'm afraid I don't
find the website for Indy terribly easy to navigate around, given the
two different "halves") but it's empty. Are you monitoring it, and
would it be better to go there?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: Yes, it sounds like Delphi's idea of a stream isn't the same as .NETs.
If I have a method which returns a stream, I don't need to care which
type of stream it is - I can just read from it.
Yes. In .net a stream is more like a "handle". I know its not really a
handle - but to the end user its treated a bit the same.
Ah, right. Okay, it makes a bit more sense now - and the above would be
fine in .NET too. When you'd talked about it being much easier to
convert a stream to text in Delphi, the example you gave was a pretty
tortuous one where I'd rarely design an interface in that way.
Yes - maybe I should convert the demo to do something else - but was trying
to keep the demo simple. I can change it to write to a file instead next
round.
I'll make an update soon, Im working on the class name changes now. Its
what I inteded to convey.
Okay. While you're at the updating business, could you change it to not
create an instance of ASCIIEncoding? Using the static Encoding.ASCII
property is much neater, IMO :)
Aah, didnt know about that. Looked all over for a static one. :)
Ill prob change it to go to a file though.
Again - there may be more suitable adaptors. TStrings is kind of like a
C++ vector, its not really an array. Is there a better .net concept to
map it to?
StringCollection, probably.
I'll look a that then. Is this a "commonly" used class in .net that users
will be familiar with?
Damn :(
I presume it would be against the Borland licence to modify the runtime
library (.NET version) to add the extra implicit conversions?
It depends. I think its allowed if we dont redistribute that class itself
for resuse. But since everything in a .net asm is "public". There isnt a
way to declare class "internal" only is there? :)
But see next message - it might be solved...
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: Again - there may be more suitable adaptors. TStrings is kind of like a
C++ vector, its not really an array. Is there a better .net concept to
map it to?
StringCollection, probably.
I'll look a that then. Is this a "commonly" used class in .net that users
will be familiar with?
Fairly. There's also ArrayList which is more common, but not typesafe
(i.e. it can store any object references, not just strings).
I presume it would be against the Borland licence to modify the runtime
library (.NET version) to add the extra implicit conversions?
It depends. I think its allowed if we dont redistribute that class itself
for resuse. But since everything in a .net asm is "public". There isnt a
way to declare class "internal" only is there? :)
Yes there is - declare it as internal and it's only available within
that assembly.
But see next message - it might be solved...
I await it eagerly :)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in news:MPG.1a7f18c1f275afdf989fb3
@msnews.microsoft.com: Fairly. There's also ArrayList which is more common, but not typesafe
(i.e. it can store any object references, not just strings).
This would be only strings.
Yes there is - declare it as internal and it's only available within
that assembly.
But I'd have to modify the Borland sources. :)
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: Jon Skeet [C# MVP] <sk***@pobox.com> wrote in news:MPG.1a7f18c1f275afdf989fb3
@msnews.microsoft.com: Fairly. There's also ArrayList which is more common, but not typesafe
(i.e. it can store any object references, not just strings).
This would be only strings.
Right. StringCollection would be a good bet then. Yes there is - declare it as internal and it's only available within
that assembly.
But I'd have to modify the Borland sources. :)
Or do it post build, by disassembling the IL, adding in the conversion
and then reassembling. Much the same effect, really.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: Would there be a better newsgroup to discuss this in, by the way? It's
Hmm. Maybe framework? We could really get the discussion going there. :) :)
not very closely related to C#. I see there's a dotnet Indy newsgroup
on the Atozed server (which I eventually found - I'm afraid I don't
find the website for Indy terribly easy to navigate around, given the
Halves as in .net and VCL? Suggestions are always welcome - the website is
lacking time and a permanent webmaster. We just did a revamp, you should have
seen it two weeks ago. ;)
Most Delphi users are in the NGs and just come to the website for downloads.
Indy ships as part of Delphi, C++ Builder and Kylix as well and Borland uses
it in the products as well, so it has a lot of exposure. :)
two different "halves") but it's empty. Are you monitoring it, and
would it be better to go there?
Yes it would probably be better. Most of the Indy team monitors that too so
there will be very good input from them.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Chad Z. Hower aka Kudzu wrote: I forgot to add:
2) If you are interested, you can use this form to contact me as I am the
chairman of Mercury Team which is the administrative team for Indy.
<http://www.hower.org/kudzu/Mail.html>
Hi Chad -
I tried to use the form to contact you but I keep getting the same error:
"Cannot send mail - check mail server settings"
I am interested in helping out with this project. What is the best way to
contact you? TIA
--
chris
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: not very closely related to C#. I see there's a dotnet Indy newsgroup
on the Atozed server (which I eventually found - I'm afraid I don't
find the website for Indy terribly easy to navigate around, given the
Halves as in .net and VCL? Suggestions are always welcome - the website is
lacking time and a permanent webmaster. We just did a revamp, you should have
seen it two weeks ago. ;)
Nope - halves as in the bit on http://www.indyproject.org and the bit
on http://www.atozed.com/indy
Most Delphi users are in the NGs and just come to the website for downloads.
Indy ships as part of Delphi, C++ Builder and Kylix as well and Borland uses
it in the products as well, so it has a lot of exposure. :)
Right. two different "halves") but it's empty. Are you monitoring it, and
would it be better to go there?
Yes it would probably be better. Most of the Indy team monitors that too so
there will be very good input from them.
Okay. Do you want to post an appropriate state of where you think we
are? (I would, but I don't know how much you want to explain to the
regulars there - you know them better than I do.)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP***********************@msnews.microsoft.co m: Nope - halves as in the bit on http://www.indyproject.org and the bit
on http://www.atozed.com/indy
Aah. Yes the other projects did goof up our structure. Any changes suggested
to the front page?
Okay. Do you want to post an appropriate state of where you think we
are? (I would, but I don't know how much you want to explain to the
regulars there - you know them better than I do.)
Just drop a note in with a one or two paragraph sentence - The Indy team is
very friendly and you wont have any troubles.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
chris <ne********@boxfrog.com> wrote in news:b8adnXd9pdYmkIjdRVn- gg@comcast.com: I tried to use the form to contact you but I keep getting the same error:
"Cannot send mail - check mail server settings"
Aah sorry about that. We've been moving mail servers. I fixed it and the form
works now.
I am interested in helping out with this project. What is the best way to
Great!
contact you? TIA
You can try the form again, or you can just join in our .dotnet newsgroup at:
news.atozedsoftware.com
As you can see we are underway, but can definitely use some more "VS
natives".
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP***********************@msnews.microsoft.co m: Nope - halves as in the bit on http://www.indyproject.org and the bit
on http://www.atozed.com/indy
Aah. Yes the other projects did goof up our structure. Any changes suggested
to the front page?
It's not so much the front page, as getting all the information
together on *one* site. It's just a bit confusing at the moment. Okay. Do you want to post an appropriate state of where you think we
are? (I would, but I don't know how much you want to explain to the
regulars there - you know them better than I do.)
Just drop a note in with a one or two paragraph sentence - The Indy team is
very friendly and you wont have any troubles.
Righto, will do.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: It's not so much the front page, as getting all the information
together on *one* site. It's just a bit confusing at the moment.
Orginally indy.html was the front page, but then we had to add the other
projects in. It really made havoc thats not completely fixed yet - hopefully
once you get to the indy.html page its a bit easier.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: It's not so much the front page, as getting all the information
together on *one* site. It's just a bit confusing at the moment.
Orginally indy.html was the front page, but then we had to add the other
projects in. It really made havoc thats not completely fixed yet - hopefully
once you get to the indy.html page its a bit easier.
I think you misunderstand - it's not that there are multiple projects,
it's that half of the pages about Indy are on http://www.indyproject.org, and the other half are on http://www.azoted.com/indy. For instance, the news server details are
on the azoted site, and getting from one to the other involves the
browser bringing up a new window automatically - hardly ideal.
I have problem with the top level page having three different projects
on, although a consistent style with a link back to the top level page
would help.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP***********************@msnews.microsoft.co m: http://www.azoted.com/indy. For instance, the news server details are
on the azoted site, and getting from one to the other involves the
browser bringing up a new window automatically - hardly ideal.
Aah - thats because all external pages are set to come up in a new window.
And the newsserver is actually hosted by Atozed, thus its their page as they
maintain it and all details abou tit.
I have problem with the top level page having three different projects
on, although a consistent style with a link back to the top level page
would help.
Thats the artifacts I talked about with one project becoming 3... going to
take some time to sort out.
BTW - are you monitoring the other groups as frequent? I posted two new
issues over there.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com
Chad Z. Hower aka Kudzu <cp**@hower.org> wrote: Aah - thats because all external pages are set to come up in a new
window. And the newsserver is actually hosted by Atozed, thus its
their page as they maintain it and all details abou tit.
Yes, I understand the reasoning behind it - but it's still confusing,
to be honest.
I have problem with the top level page having three different projects
on, although a consistent style with a link back to the top level page
would help.
Thats the artifacts I talked about with one project becoming 3... going to
take some time to sort out.
Sorry, there should havebeen a "no" between "I" and "have". Basically
it's not an issue for me while I'm only interested in the main library.
BTW - are you monitoring the other groups as frequent? I posted two new
issues over there.
Fairly frequently, yes :)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om: 1) The naming/organization conventions
For others following this thread, the new build has this addressed.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"
ELKNews - Get your free copy at http://www.atozedsoftware.com This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Bryan Olson |
last post by:
Here's the problem: Suppose we use:
import socket
f = some_socket.makefile()
Then:
f.read() is efficient, but verbose, and incorrect (or at
least does not play will with others);
|
by: basecamp |
last post by:
just checking the average age of programmers using this group
--
thanks
|
by: Alex Martinoff |
last post by:
Using the org.postgresql.Driver JDBC driver is it possible to connect
to Postgres using a unix domain socket instead of a TCP socket (so you
don't have to start the postmaster with -i)? Using a TCP...
|
by: Jim Isaacson |
last post by:
Hi
I'm looking for some help or a sample of a socket call to talk to a telnet
server and send a telnet break from a C program. I've looked at the Stevens
book and tried examples of his daytime...
|
by: Kevin |
last post by:
Hey guys. I'm looking to get together some VB programmers on Yahoo
messenger. I sit at a computer and program all day.
I have about 3 or 4 people already, but it would be really cool to
have a...
|
by: M_Mann |
last post by:
Hello,
Pls excuse if you consider this off-topic. Conceptual artists seek
programmers here.
We are authors of "Exhibition of Living Managers" (MANAGEX,
www.managex.info) which is is global...
|
by: JDavis |
last post by:
I have created a static class-level socket for use by the class member
functions:
static Socket s = new Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp);
The Connect...
|
by: Nicolas Le Gland |
last post by:
Hello everyone here.
This is my first post in this newsgroup, I hope I won't be to much
off-topic. Feel free to redirect me to any better group.
I am getting strange timing issues when...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: DJRhino |
last post by:
Was curious if anyone else was having this same issue or not....
I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
|
by: tracyyun |
last post by:
Hello everyone,
I have a question and would like some advice on network connectivity. I have one computer connected to my router via WiFi, but I have two other computers that I want to be able to...
|
by: NeoPa |
last post by:
Hello everyone.
I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report).
I know it can be done by selecting :...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be using a very simple database which has Form (clsForm) & Report (clsReport) classes that simply handle making the calling Form invisible until the Form, or all...
|
by: Teri B |
last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course.
0ne-to-many. One course many roles.
Then I created a report based on the Course form and...
|
by: nia12 |
last post by:
Hi there,
I am very new to Access so apologies if any of this is obvious/not clear.
I am creating a data collection tool for health care employees to complete. It consists of a number of...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be focusing on the Report (clsReport) class. This simply handles making the calling Form invisible until all of the Reports opened by it have been closed, when it...
|
by: GKJR |
last post by:
Does anyone have a recommendation to build a standalone application to replace an Access database? I have my bookkeeping software I developed in Access that I would like to make available to other...
| |
