1. The Archive and version compatability
- Posted by jeremy (admin) Mar 25, 2009
- 976 views
Since we are going to use the description for version compatability, can we all do our best to include something searchable? I am up for suggestions on what we should use, but I'll start with a few ideas:
REQUIRES: 4.x
This has a keyword to indicate that it REQUIRES something, however, when searching the archive right now for "requires 4" I get all sorts of things, anything with the word REQUIRE and the number 4. For instance, here's the first match:
WIN Binder GUI Interface 210K Rod Damon Nov 7/05 1.00 A Windows GUI interface for binding and shrouding with Euphoria 2.4 & 2.5. Has been tested on WIN98 & XP for Windows & DOS. Written using Andrea Cini's EuWinGUI library. Requires the 2.4 or 2.5 RDS registered binder/shrouder (not included).
This clearly does not require 4.x.
REQ40
This will be a good match, but pretty hard to read when put in with other text, but I am afraid we are going to have to go with something like this. Now, a further problem is going to be how to indicate something works on 2.x, 3.x and 4.x. We need to indicate that (as opposed to just leaving it blank) because The Archive has a ton of packages in it that will probably never be updated for 4.0 and most have no type of version indication.
Maybe we should have another keyword that we use such as COMPAT40, COMPAT31, COMPAT25 or something like that. So, a description may be:
This is my pacakge that does something good. COMPAT25, COMPAT30, COMPAT31, COMPAT40, COMPAT41
If we fail to do something like this, then the archive will not be searchable. For instance, I want to search for any advanced math library that I know works with 40. My search term would be: math COMPAT40
Just thinking aloud on how to solve this problem. I'm very afraid that even if we agree on a common term that the archive is going to be pretty messy to find anything in because we will all forget, or mistype a character or simply not know, but we must do our best with what we have.
Thoughts?
Jeremy
2. Re: The Archive and version compatability
- Posted by DanM Mar 25, 2009
- 945 views
How about "RequiresVersion4"?
It's ungrammatical, & I'd be one of the first to complain in that regard, but it would simplify searching, in that neither "Requires", nor "Version", nor "4" would, by themselves, be found, I think.
Dan
3. Re: The Archive and version compatability
- Posted by DanM Mar 25, 2009
- 959 views
How about "RequiresVersion4"?
It's ungrammatical, & I'd be one of the first to complain in that regard, but it would simplify searching, in that neither "Requires", nor "Version", nor "4" would, by themselves, be found, I think.
Dan
Maybe it should instead be "RequiresVersion", and then the searcher would still have to see which versions show up as a result?
Or, "Requires VersionX", then search for "VersionX"?
Dan
4. Re: The Archive and version compatability
- Posted by jeremy (admin) Mar 25, 2009
- 959 views
How about "RequiresVersion4"?
It's ungrammatical, & I'd be one of the first to complain in that regard, but it would simplify searching, in that neither "Requires", nor "Version", nor "4" would, by themselves, be found, I think.
Maybe it should instead be "RequiresVersion", and then the searcher would still have to see which versions show up as a result?
Or, "Requires VersionX", then search for "VersionX"?
As I was thinking about it, maybe we don't even need the "Requires VersionX" but simply a "Compat VersionX" because, for the most part, I could care less if it Requires 4 or Requires 3. I just want to know that it is Compatible with 4 or Compatible with 3?
Jeremy
5. Re: The Archive and version compatability
- Posted by DanM Mar 25, 2009
- 970 views
As I was thinking about it, maybe we don't even need the "Requires VersionX" but simply a "Compat VersionX" because, for the most part, I could care less if it Requires 4 or Requires 3. I just want to know that it is Compatible with 4 or Compatible with 3?
Jeremy
Yeah, I think that makes better sense. And even with concerns with misspelling, maybe "Compatible VersionX" would be better? "Compat" just looks weird.
Dan
6. Re: The Archive and version compatability
- Posted by bernie Mar 25, 2009
- 974 views
How about "RequiresVersion4"?
It's ungrammatical, & I'd be one of the first to complain in that regard, but it would simplify searching, in that neither "Requires", nor "Version", nor "4" would, by themselves, be found, I think.
Maybe it should instead be "RequiresVersion", and then the searcher would still have to see which versions show up as a result?
Or, "Requires VersionX", then search for "VersionX"?
As I was thinking about it, maybe we don't even need the "Requires VersionX" but simply a "Compat VersionX" because, for the most part, I could care less if it Requires 4 or Requires 3. I just want to know that it is Compatible with 4 or Compatible with 3?
Jeremy
Why are you worrying about this ??
Any user downloading code from the archive before
ver 3 is not going to be able to use the code unless
they have the binaries so place all that code in a
separate directory called out of date code.
Make a special compatibility list or mark ver 4 code as
it is added to the archive.
Then any code not marked ver 4 should be only used on
ver 3.
7. Re: The Archive and version compatability
- Posted by jeremy (admin) Mar 25, 2009
- 967 views
Why are you worrying about this ??
Any user downloading code from the archive before
ver 3 is not going to be able to use the code unless
they have the binaries so place all that code in a
separate directory called out of date code.
Make a special compatibility list or mark ver 4 code as
it is added to the archive.
Then any code not marked ver 4 should be only used on
ver 3.
Bernie, There are plenty of things in the archive that work with 2.5, and some people may still have 2.5 installed on their system. Further, we do not have control of the archive, we cannot move anything. Even if it were moved, that would require changes to the archive script which RDS doesn't want to do right now. As for the special compatibility list or marking for 4.0, that too would require changes to the script. So, we are trying to figure out how to work within the confines we have been given.
Now, it's very possible to have code that works on 2.x, 3.x and 4.x w/o issue, so we need some way of indicating that as well.
Jeremy
8. Re: The Archive and version compatability
- Posted by bernie Mar 25, 2009
- 953 views
Why are you worrying about this ??
Any user downloading code from the archive before
ver 3 is not going to be able to use the code unless
they have the binaries so place all that code in a
separate directory called out of date code.
Make a special compatibility list or mark ver 4 code as
it is added to the archive.
Then any code not marked ver 4 should be only used on
ver 3.
Bernie, There are plenty of things in the archive that work with 2.5, and some people may still have 2.5 installed on their system. Further, we do not have control of the archive, we cannot move anything. Even if it were moved, that would require changes to the archive script which RDS doesn't want to do right now. As for the special compatibility list or marking for 4.0, that too would require changes to the script. So, we are trying to figure out how to work within the confines we have been given.
Now, it's very possible to have code that works on 2.x, 3.x and 4.x w/o issue, so we need some way of indicating that as well.
Jeremy
Some code 2.5 and before is shrouded how are you going to
deal with that.
Who is going to go through all the code in the archive and
decide what version it's for and try it and mark it??
Who is going to spend the hours of answering questions
about how to change the old code to work with ver 4.
As for me I am writing new code for ver 4.0 to take advantage
of the new features and pulling my old code from the archive
I think your creating a lot of work that no one is going to
volunteer to perform.
9. Re: The Archive and version compatability
- Posted by jeremy (admin) Mar 25, 2009
- 947 views
Some code 2.5 and before is shrouded how are you going to deal with that.
Who is going to go through all the code in the archive and decide what version it's for and try it and mark it??
Who is going to spend the hours of answering questions about how to change the old code to work with ver 4.
As for me I am writing new code for ver 4.0 to take advantage of the new features and pulling my old code from the archive.
I think your creating a lot of work that no one is going to volunteer to perform.
I am not at all suggesting that we mark previous entries or even try to categorize previous entries in any systematic way. What I am suggesting is code that we are writing today, tomorrow and the next day have some type of standard tagging on it. I have written code that works in 4.0 and 3.1. If it were of general use and I upload it to the archive tomorrow, I want to be able to specify that it works in 3.1 and 4.0 with some type of common tag.
Now, what was discussed in the past was if you downloaded a library from the archive that looked nice and it didn't work on 4.0, then you should have been able to click a button on the entry in the archive that said "Does not work in 4.0" or something to that effect, so that others would know as well, but that idea has been canned as the the archive script will not be updated.
I am in no way suggesting anyone go back and try to update everything or even mark everything. I am specifically stating about from today forward.
Now, who is going to answer questions on converting code from 3.x to 4.0? I hope everyone on the forum. We all have code in 3.1 that is going to need to be converted. Not from the archive at all, our own personal code. I would venture to say we are all going to get pretty good about updating 3.x code to 4.0.
Jeremy
P.S. The \\ in your messages is not required and should not be used. Just type away, the forum will word wrap the text for each persons browser width. When you want to start a new paragraph, leave an empty line between the previous sentence.
10. Re: The Archive and version compatability
- Posted by achury Mar 25, 2009
- 1003 views
Archive never had version advice.
If you see a file date 1999, by sure is not Eu4.0 code
Is just a little of common sense, if you download very old code, by sure was developed for an old interpreter and by sure you must to do some fixing.
11. Re: The Archive and version compatability
- Posted by jeremy (admin) Mar 25, 2009
- 984 views
Archive never had version advice.
If you see a file date 1999, by sure is not Eu4.0 code
Is just a little of common sense, if you download very old code, by sure was developed for an old interpreter and by sure you must to do some fixing.
Actually, that's the point. I downloaded DOT from Daivd Cuny, and it worked fine on 4.0. It was last updated in 1998! Now, it's a pre-processor and therefore doesn't support some of the new language constructs, but it ran fine and was last modified in 1998. I am betting that we will find all sorts of things like this that run in 4.0 w/o issue. With DOT I didn't have to change one single thing.
Jeremy
12. Re: The Archive and version compatability
- Posted by euphoric (admin) Mar 25, 2009
- 1033 views
I think the obvious solution is for somebody to create (or rewrite) a Code Archive manager and host it at a new URL (like www.EuphoriaRepo.com or www.OpenEuphoria.org/coderepo).
Any items currently in RDS' archive can either be moved by the author or by a volunteer. If each of us did two or three items a day, we could move it all over in a week or two.
Or even make it automated. I'm sure Rob could supply a usable list of the current archive contents.
I nominate Jeremy!
13. Re: The Archive and version compatability
- Posted by jeremy (admin) Mar 25, 2009
- 986 views
I think the obvious solution is for somebody to create (or rewrite) a Code Archive manager and host it at a new URL (like www.EuphoriaRepo.com or www.OpenEuphoria.org/coderepo).
Rob would like to keep the archive on his site. They enjoy maintaining it.
Jeremy
14. Re: The Archive and version compatability
- Posted by euphoric (admin) Mar 25, 2009
- 973 views
I think the obvious solution is for somebody to create (or rewrite) a Code Archive manager and host it at a new URL (like www.EuphoriaRepo.com or www.OpenEuphoria.org/coderepo).
Rob would like to keep the archive on his site. They enjoy maintaining it.
Oh.
Well, if we want advanced functionality and they're not willing to implement it such that it hampers innovation... we could always mutiny and take over the ship.
(Don't tell Rob I said that.)
15. Re: The Archive and version compatability
- Posted by Kat Mar 25, 2009
- 1000 views
I think the obvious solution is for somebody to create (or rewrite) a Code Archive manager and host it at a new URL (like www.EuphoriaRepo.com or www.OpenEuphoria.org/coderepo).
Rob would like to keep the archive on his site. They enjoy maintaining it.
Jeremy
That's kinky.
But does that preclude having a detailed search facility on another site? Because i have openeuphoria.com and this Tiggr bot which already has the archives un-zipped and indexed, you see....
useless
16. Re: The Archive and version compatability
- Posted by euphoric (admin) Mar 25, 2009
- 994 views
I think the obvious solution is for somebody to create (or rewrite) a Code Archive manager and host it at a new URL (like www.EuphoriaRepo.com or www.OpenEuphoria.org/coderepo).
Rob would like to keep the archive on his site. They enjoy maintaining it.
That's kinky.
But does that preclude having a detailed search facility on another site? Because i have openeuphoria.com and this Tiggr bot which already has the archives un-zipped and indexed, you see....
Okay, scratch my vote for Jeremy, I vote for useless! I mean Kat!
17. Re: The Archive and version compatability
- Posted by Kat Mar 27, 2009
- 982 views
- Last edited Mar 28, 2009
I think the obvious solution is for somebody to create (or rewrite) a Code Archive manager and host it at a new URL (like www.EuphoriaRepo.com or www.OpenEuphoria.org/coderepo).
Rob would like to keep the archive on his site. They enjoy maintaining it.
That's kinky.
But does that preclude having a detailed search facility on another site? Because i have openeuphoria.com and this Tiggr bot which already has the archives un-zipped and indexed, you see....
Okay, scratch my vote for Jeremy, I vote for useless! I mean Kat!
Sorry to say, but due to an incident on irc, i won't be putting the db access online. I deleted the entire dir off the host, a host i just paid for.
I also won't be completing http.e, or submitting any other code. This will make more than one person happy as h, i know. I refuse to be drawn into more defensive positions. You want it?, you code it, you fight for it.
useless
18. Re: The Archive and version compatability
- Posted by jeremy (admin) Mar 27, 2009
- 935 views
- Last edited Mar 28, 2009
Sorry to say, but due to an incident on irc, i won't be putting the db access online. I deleted the entire dir off the host, a host i just paid for.
I also won't be completing http.e, or submitting any other code. This will make more than one person happy as h, i know. I refuse to be drawn into more defensive positions. You want it?, you code it, you fight for it.
I'm trying to protect the #euphoria IRC channel as it's a valuable resource for Euphoria, otherwise I wouldn't respond here. But the incident was one person on IRC stating that during a GET or POST request via HTTP, that the referrer should not default. If it is not present, then it should not be given in the HTTP headers. The official specification supports this claim. Kat's experience has been that she has been blocked downloading items that have no referer, the other claimed that some web hosts block spoofed referrer headers because it's often used in spam bots. Nothing bad was said only a disagreement as to which was right.
Jeremy
19. Re: The Archive and version compatability
- Posted by Kat Mar 27, 2009
- 956 views
- Last edited Mar 28, 2009
Sorry to say, but due to an incident on irc, i won't be putting the db access online. I deleted the entire dir off the host, a host i just paid for.
I also won't be completing http.e, or submitting any other code. This will make more than one person happy as h, i know. I refuse to be drawn into more defensive positions. You want it?, you code it, you fight for it.
I'm trying to protect the #euphoria IRC channel as it's a valuable resource for Euphoria, otherwise I wouldn't respond here. But the incident was one person on IRC stating that during a GET or POST request via HTTP, that the referrer should not default. If it is not present, then it should not be given in the HTTP headers. The official specification supports this claim. Kat's experience has been that she has been blocked downloading items that have no referer, the other claimed that some web hosts block spoofed referrer headers because it's often used in spam bots. Nothing bad was said only a disagreement as to which was right.
Jeremy
A valid on-site header trumps no header. It's not about spoofing anything with malicious intent. It's not about malformed header lines. And sending the host address as the referer: tag does no harm. There is code to allow the http.e user to set the line to anything desired (except "", currently), just like setting the user-agent: line. I offered to code to allow "" be set, so the referer would not be sent, but that was declined.
I point out that using http.e with a user-agent line of anything other than http.e is worse than specifying the host name as referer.
I've run across domains before that allowed page views (yes, that is a "download") *only* if refered to by another page on their domain, which meant that bookmarking the desired page didn't work, shortcuts didn't work, offsite references by other hosts didn't work, the domain in question missed one or two web ad hits, etc etc etc.. Making life easier by sending the domain name of the host you are accessing hurts no more than http.e having :
public procedure set_sendheader_useragent_msie() set_sendheader("User-Agent","Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)") end procedure
in it, or me coding
{"User-Agent",": ","Opera/5.02 (Windows 98; U) [en]"}, --</joke> pick your own
Frying my tail over something this trivial tells me just how much i am:
useless
20. Re: The Archive and version compatability
- Posted by jimcbrown (admin) Mar 28, 2009
- 955 views
A valid on-site header trumps no header.
For the "referer:" header, this is what the disagreement was about. The RFC says otherwise. This was not meant to refer to your coding skills or usefulness in general - this was a relatively minor detail that CoJaBo was trying to straigthen out.
In any case, the question was what to do with default behavior, and let the user customize if they choose. That the user should be able to change the behavior either way was universially agreed apon.
(For the record, I later told CoJaBo that we should make the default behavior what you said simply because you have 14+ years experience on this topic.)
It's not about spoofing anything with malicious intent. It's not about malformed header lines. And sending the host address as the referer: tag does no harm.
CoJaBo personally knew of sites that would assume malicious intent if one sent the host address as the referer: tag, so there might be harm.
On the other hand, you personally knew of sites where not sending the referer: header at all also caused the exact same sort of harm.
If both are true, then this is perhaps a no-win situation.
There is code to allow the http.e user to set the line to anything desired (except "", currently), just like setting the user-agent: line. I offered to code to allow "" be set, so the referer would not be sent, but that was declined.
Sending a header of 'Referer: ' or 'Referer: ""' was bad.
However, the suggestion to use "" to mean, Don't send any Referer header at all, was universally accepted afaict. The issue was only pushed to make that ability also the default behavior.
I point out that using http.e with a user-agent line of anything other than http.e is worse than specifying the host name as referer.
And all agreed that you were correct.
I've run across domains before that allowed page views (yes, that is a "download") *only* if refered to by another page on their domain, which meant that bookmarking the desired page didn't work, shortcuts didn't work, offsite references by other hosts didn't work, the domain in question missed one or two web ad hits, etc etc etc.. Making life easier by sending the domain name of the host you are accessing hurts no more than http.e having :
public procedure set_sendheader_useragent_msie() set_sendheader("User-Agent","Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)") end procedure
in it, or me coding
{"User-Agent",": ","Opera/5.02 (Windows 98; U) [en]"}, --</joke> pick your own
CoJaBo personally knew of sites where setting the referer: header to the hostname caused an anti-spam-bot block. From that I conclude that the harm level is measurable and must be considered.
Again, remember that this is about DEFAULT BEHAVIOR. So this isn't about making your life any easier, but others.
Frying my tail over something this trivial tells me just how much i am:
useless
Agreed, there is no need to get emotional about such a trivial aspect.
21. Re: The Archive and version compatability
- Posted by Kat Mar 28, 2009
- 943 views
Agreed, there is no need to get emotional about such a trivial aspect.
Except declining my experience says my experience is worthless too. I have never run into a site where sending the hostname in the refer tag caused the webpage to not arrive. I would not have gone to the trouble of coding the default, if it wasn't needed, and i wouldn't have coded it if i had run into a site where it was a problem.
The rfc says the refer shouldn't be sent if the originating site isn't known, like if the user typed the url in from the keybd having never been to the host domain. It doesn't suggest anything more than that. And the entire document is a suggestion, it's a request for comments, it's not a strict standard, and there's a number of non-standards in wide use, like MS's IE. But if you are browsing around a site, then the host is indeed the origin of the urls you are clicking on. Rfc2616 wording on refer is identical to rfc2068 in this regard. It does not prohibit sending the source site of the url if you know it, it suggests you do send it. It doesn't mandate it be sent at all, ever, but some sites demand it, so i coded it.
useless
22. Re: The Archive and version compatability
- Posted by euphoric (admin) Mar 28, 2009
- 919 views
- Last edited Mar 29, 2009
There's an Apache directive for .htaccess files that denies retrieval of web resources if the referrer did not come from the host site.
Hope this helps.