Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #104957 > unrolled thread

WP-A: A New URL Shortener

Back to article view | Back to comp.lang.python

Contents

  WP-A: A New URL Shortener Vinicius Mesel <me@vmesel.com> - 2016-03-15 16:56 -0300
    Re: WP-A: A New URL Shortener Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-15 23:53 +0100
      Re: WP-A: A New URL Shortener Erik <python@lucidity.plus.com> - 2016-03-15 23:11 +0000
      Re: WP-A: A New URL Shortener Chris Angelico <rosuav@gmail.com> - 2016-03-16 10:16 +1100
        Re: WP-A: A New URL Shortener Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-16 00:38 +0100
          Re: WP-A: A New URL Shortener Chris Angelico <rosuav@gmail.com> - 2016-03-16 10:55 +1100
            Re: WP-A: A New URL Shortener Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-16 01:36 +0100
          Re: WP-A: A New URL Shortener Gene Heskett <gheskett@wdtv.com> - 2016-03-15 22:34 -0400
            Re: WP-A: A New URL Shortener Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-16 03:46 +0100
              Re: WP-A: A New URL Shortener Gene Heskett <gheskett@wdtv.com> - 2016-03-15 23:34 -0400
          Re: WP-A: A New URL Shortener Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-03-16 17:51 +1100
        Re: WP-A: A New URL Shortener Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-03-16 17:27 +1300
          Re: WP-A: A New URL Shortener Chris Angelico <rosuav@gmail.com> - 2016-03-16 16:43 +1100
            Re: WP-A: A New URL Shortener Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-17 19:27 +0100
              Re: WP-A: A New URL Shortener Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-17 13:40 -0700
                Re: WP-A: A New URL Shortener Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-17 22:15 +0100
                  Re: WP-A: A New URL Shortener Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-17 21:49 -0700
                    Re: WP-A: A New URL Shortener Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-19 14:03 +0100
      Re: WP-A: A New URL Shortener Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-15 16:19 -0700
        Re: WP-A: A New URL Shortener Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-03-16 01:22 +0100
          Re: WP-A: A New URL Shortener Rick Johnson <rantingrickjohnson@gmail.com> - 2016-03-15 20:40 -0700
      Re: WP-A: A New URL Shortener Erik <python@lucidity.plus.com> - 2016-03-15 23:40 +0000
      Re: WP-A: A New URL Shortener Chris Angelico <rosuav@gmail.com> - 2016-03-16 10:48 +1100
      Re: WP-A: A New URL Shortener Erik <python@lucidity.plus.com> - 2016-03-16 00:31 +0000
      Re: WP-A: A New URL Shortener Chris Angelico <rosuav@gmail.com> - 2016-03-16 11:34 +1100
      Re: WP-A: A New URL Shortener Chris Angelico <rosuav@gmail.com> - 2016-03-17 23:08 +1100
        Re: WP-A: A New URL Shortener Dan Sommers <dan@tombstonezero.net> - 2016-03-17 12:47 +0000

Page 1 of 2  [1] 2  Next page →

#104957 — WP-A: A New URL Shortener

Hey guys,

I'm a 16 year old Python Programmer that wanted to do something different.
But, like we know, ideas are quite difficult to find.
So I decided to develop a URL Shortener to help the Python community out and share my coding knowledge, and today the project was launched with its first stable version.
So if you want to see the software working, go check it out at: http://wp-a.co/
Or if you want to see the source code to contribute and help the project: https://github.com/vmesel/WP-A.CO


Hugs,
Vinicius Mesel
Brazilian and Portuguese Speaker
http://www.vmesel.com

[toc] | [next] | [standalone]

#104960

Vinicius Mesel wrote:

> I'm a 16 year old Python Programmer that wanted to do something different.
> But, like we know, ideas are quite difficult to find.
> So I decided to develop a URL Shortener to help the Python community out
> and share my coding knowledge, and today the project was launched with its
> first stable version. So if you want to see the software working, go check
> it out at: http://wp-a.co/ Or if you want to see the source code to
> contribute and help the project: https://github.com/vmesel/WP-A.CO

While I commend your efforts, I think that you should have chosen another 
topic for your project.  It is also hard for me to see in which way this is 
“something different” – are there not enough “URL Shorteners” already? –, 
and how a “URL Shortener” could “help the Python community out”.

Because I think that “URL Shorteners” are a bad idea in the first place: One 
never knows for how long a time a “short URL” works, who is listening in the 
middle, and what they are referring to, until one uses them at which point 
it is too late.  If a “short URL” expires, there is *no way* to retrieve the 
referred content; when a *real* URI breaks, there are services like the 
Internet Archive and the Google cache to help one out.  So when I see a 
“short URL”, I tend not to use it.

I find it particularly disturbing that in wpa.py:processaURL() your software 
apparently stores the original URIs in an SQL database; in the case of your 
proof-of-concept, in *your* database.  So *you* are listening in the middle 
then.  I cannot be sure because I have not thought this through, but with 
aliases for common second-level domains, and with text compression, it 
should be possible to do this without a database.

So sorry, because of that already, I will certainly not use or recommend 
your service.  “Leave others the privacies of their minds and lives. 
Intimacy remains precious only insofar as it is inviolate.” ─Surak

And with the exception of Twitter-ish sites that place a limit on message 
length, there really is *no need* for shorter URIs nowadays.  (HTTP) clients 
and servers are capable of processing really long ones [1]; electronic 
communications media and related software, too [2].  And data storage space 
as well as data transmission has become exceptionally inexpensive.  A few 
less bytes there do not count.

Instead, there *is* a need for *concise*, *semantic* URIs that Web (service) 
users can *easily* *remember*.  It is the duty of the original Web 
authors∕developers to make sure that there are, and I think that no kind of 
automation is going to ease or replace thoughtful path design anytime soon 
(but please, prove me wrong):

<https://www.w3.org/QA/Tips/uri-choose>

__________
[1] <http://stackoverflow.com/a/417184/855543>
[2] <http://tools.ietf.org/html/rfc3986#appendix-C>
-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#104962

On 15/03/16 22:53, Thomas 'PointedEars' Lahn wrote:
> A few
> less bytes there do not count.

You mean "Fewer bytes there do not count".

E.

(But on the whole, yes, I do agree with your position in this instance.
Kudos to Vinicius for doing something productive with his time though - 
I'm sure a lot has been learned in putting that together).

[toc] | [prev] | [next] | [standalone]

#104963

On Wed, Mar 16, 2016 at 9:53 AM, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:
> Vinicius Mesel wrote:
>
>> I'm a 16 year old Python Programmer that wanted to do something different.
>> But, like we know, ideas are quite difficult to find.
>> So I decided to develop a URL Shortener to help the Python community out
>> and share my coding knowledge, and today the project was launched with its
>> first stable version. So if you want to see the software working, go check
>> it out at: http://wp-a.co/ Or if you want to see the source code to
>> contribute and help the project: https://github.com/vmesel/WP-A.CO
>
> I find it particularly disturbing that in wpa.py:processaURL() your software
> apparently stores the original URIs in an SQL database; in the case of your
> proof-of-concept, in *your* database.  So *you* are listening in the middle
> then.  I cannot be sure because I have not thought this through, but with
> aliases for common second-level domains, and with text compression, it
> should be possible to do this without a database.

How? If you shorten URLs, you have to be able to reconstruct the long
ones. Compression can't do that to arbitrary lengths. Somewhere there
needs to be the rest of the information.

> And with the exception of Twitter-ish sites that place a limit on message
> length, there really is *no need* for shorter URIs nowadays.  (HTTP) clients
> and servers are capable of processing really long ones [1]; electronic
> communications media and related software, too [2].  And data storage space
> as well as data transmission has become exceptionally inexpensive.  A few
> less bytes there do not count.

There are many places where there are limits (hard or soft) on message
lengths. Some of us still use MUDs and 80-character line limits.
Business cards or other printed media need to be transcribed by hand.
Dictation of URLs becomes virtually impossible when they're
arbitrarily long.

> Instead, there *is* a need for *concise*, *semantic* URIs that Web (service)
> users can *easily* *remember*.  It is the duty of the original Web
> authors∕developers to make sure that there are, and I think that no kind of
> automation is going to ease or replace thoughtful path design anytime soon
> (but please, prove me wrong):

Sure...... if you control the destination server. What if you're
engaging in scholarly discussion about someone else's content? You
can't change the canonical URLs, and you can't simply copy their
content to your own server (either for licensing reasons or to
guarantee that the official version hasn't been tampered with).

So URL shorteners are invaluable tools. However, I'm not sure what
this one is that others aren't.

ChrisA

[toc] | [prev] | [next] | [standalone]

#104965

Chris Angelico wrote:

> On Wed, Mar 16, 2016 at 9:53 AM, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:

Attribution *line*, _not_ attribution novel.

>> […] I cannot be sure because I have not thought this through, but with
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> aliases for common second-level domains, and with text compression, it
>> should be possible to do this without a database.
> 
> How? If you shorten URLs, you have to be able to reconstruct the long
> ones. Compression can't do that to arbitrary lengths. Somewhere there
> needs to be the rest of the information.

First of all, you quoted me out of context.  Please do not do that again.

Second, do you even read what you reply to?  See the markings above.

And as for second-level domains, consider for example “t.c” instead of 
“twitter.com” as part of the short URI.
 
>> And with the exception of Twitter-ish sites that place a limit on message
>> length, there really is *no need* for shorter URIs nowadays.  (HTTP)
>> clients and servers are capable of processing really long ones [1];
>> electronic communications media and related software, too [2].  And data
>> storage space as well as data transmission has become exceptionally
>> inexpensive.  A few less bytes there do not count.
> 
> There are many places where there are limits (hard or soft) on message
> lengths. Some of us still use MUDs and 80-character line limits.

See above.  Covered by [2].

But speaking of length limits, the lines in your postings are too long, 
according to Usenet convention.  I had to correct the quotations so that 
they remained readable when word-wrapped.

> Business cards or other printed media need to be transcribed by hand.
> Dictation of URLs becomes virtually impossible when they're
> arbitrarily long.

(You are not reading at all, are you?)  This is covered by that:
 
>> Instead, there *is* a need for *concise*, *semantic* URIs that Web
>> (service) users can *easily* *remember*.  It is the duty of the original
>> Web authors∕developers to make sure that there are, and I think that no
>> kind of automation is going to ease or replace thoughtful path design
>> anytime soon (but please, prove me wrong):
> 
> Sure...... if you control the destination server. What if you're
> engaging in scholarly discussion about someone else's content? You
> can't change the canonical URLs, and you can't simply copy their
> content to your own server (either for licensing reasons or to
> guarantee that the official version hasn't been tampered with).

That is why I said it is the duty of the original authors/developers.  It is 
a community effort, and it is not going to happen overnight.  But evading 
the problem with unreliable replacements such as “short URLs” is not going 
to solve it either.
 
> So URL shorteners are invaluable tools.

IBTD.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#104969

On Wed, Mar 16, 2016 at 10:38 AM, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:
> Chris Angelico wrote:
>
>> On Wed, Mar 16, 2016 at 9:53 AM, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>
>>> […] I cannot be sure because I have not thought this through, but with
>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> aliases for common second-level domains, and with text compression, it
>>> should be possible to do this without a database.
>>
>> How? If you shorten URLs, you have to be able to reconstruct the long
>> ones. Compression can't do that to arbitrary lengths. Somewhere there
>> needs to be the rest of the information.
>
> First of all, you quoted me out of context.

I trimmed the context. You got a problem with that?

> Second, do you even read what you reply to?  See the markings above.

Instead of thinking about URL shorteners specifically, think generally
about information theory. You cannot, fundamentally, shorten all URLs
arbitrarily. There just isn't enough room to store the information.

> And as for second-level domains, consider for example “t.c” instead of
> “twitter.com” as part of the short URI.

That'll work only for the ones that you code in specifically, and
that's only shortening your URL by 8 characters. A typical URL needing
shortening is over 80 characters - maybe several hundred. You need to
cut that down to a manageable length. That fundamentally cannot be
reversed without readding information.

>>> And with the exception of Twitter-ish sites that place a limit on message
>>> length, there really is *no need* for shorter URIs nowadays.  (HTTP)
>>> clients and servers are capable of processing really long ones [1];
>>> electronic communications media and related software, too [2].  And data
>>> storage space as well as data transmission has become exceptionally
>>> inexpensive.  A few less bytes there do not count.
>>
>> There are many places where there are limits (hard or soft) on message
>> lengths. Some of us still use MUDs and 80-character line limits.
>
> See above.  Covered by [2].

Unrelated. Not covered by that link. Go use a MUD some time.

> But speaking of length limits, the lines in your postings are too long,
> according to Usenet convention.  I had to correct the quotations so that
> they remained readable when word-wrapped.

Oh, so you'd rather the lines be cut to... I dunno, 80 characters?
Might be a good reason to use a URL shortener.

>> Business cards or other printed media need to be transcribed by hand.
>> Dictation of URLs becomes virtually impossible when they're
>> arbitrarily long.
>
> (You are not reading at all, are you?)  This is covered by that:
>
>>> Instead, there *is* a need for *concise*, *semantic* URIs that Web
>>> (service) users can *easily* *remember*.  It is the duty of the original
>>> Web authors∕developers to make sure that there are, and I think that no
>>> kind of automation is going to ease or replace thoughtful path design
>>> anytime soon (but please, prove me wrong):
>>
>> Sure...... if you control the destination server. What if you're
>> engaging in scholarly discussion about someone else's content? You
>> can't change the canonical URLs, and you can't simply copy their
>> content to your own server (either for licensing reasons or to
>> guarantee that the official version hasn't been tampered with).
>
> That is why I said it is the duty of the original authors/developers.  It is
> a community effort, and it is not going to happen overnight.  But evading
> the problem with unreliable replacements such as “short URLs” is not going
> to solve it either.

So, you can go fight an unwinnable battle against literally every web
creator in the world. Meanwhile, I'll keep on using URL shorteners.

ChrisA

[toc] | [prev] | [next] | [standalone]

#104975

Chris Angelico wrote:

> On Wed, Mar 16, 2016 at 10:38 AM, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
>> Chris Angelico wrote:
>>> On Wed, Mar 16, 2016 at 9:53 AM, Thomas 'PointedEars' Lahn
>>> <PointedEars@web.de> wrote:
>>>> […] I cannot be sure because I have not thought this through, but with
>>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>> aliases for common second-level domains, and with text compression, it
>>>> should be possible to do this without a database.
>>>
>>> How? If you shorten URLs, you have to be able to reconstruct the long
>>> ones. Compression can't do that to arbitrary lengths. Somewhere there
>>> needs to be the rest of the information.
>>
>> First of all, you quoted me out of context.
> 
> I trimmed the context. You got a problem with that?

Please do not insult my intelligence.  I have a problem with that you are 
not marking the omission of considerable parts of *my* text, here giving the 
wrong impression that I did not start my follow-up in an encouraging way.
 
>> Second, do you even read what you reply to?  See the markings above.
> 
> Instead of thinking about URL shorteners specifically, think generally
> about information theory. You cannot, fundamentally, shorten all URLs
> arbitrarily. There just isn't enough room to store the information.

You are the one introducing “arbitrary” here.  I am not at all convinced, 
but this discussion is beyond the scope of this newsgroup/mailing list.
 
>> But speaking of length limits, the lines in your postings are too long,
>> according to Usenet convention.  I had to correct the quotations so that
>> they remained readable when word-wrapped.
> 
> Oh, so you'd rather the lines be cut to... I dunno, 80 characters?

No, quotations ought to be word-wrapped, preserving paragraphs, in order not 
to exceed that limit.  That is why the recommended line length limit for 
posting is not 80 characters, but something from 68 to 78.

> Might be a good reason to use a URL shortener.

URIs can posted to a newsgroup/mailing list without shortening them, by 
wrapping them without breaking them.  Will you *please* read [2] to clarify 
that misconception of yours?
 
-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#104981

On Tuesday 15 March 2016 19:55:52 Chris Angelico wrote:

> On Wed, Mar 16, 2016 at 10:38 AM, Thomas 'PointedEars' Lahn
>
> <PointedEars@web.de> wrote:
> > Chris Angelico wrote:
> >> On Wed, Mar 16, 2016 at 9:53 AM, Thomas 'PointedEars' Lahn
> >>
> >> <PointedEars@web.de> wrote:
> >>> […] I cannot be sure because I have not thought this through, but
> >>> with
> >
> >                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> >>> aliases for common second-level domains, and with text
> >>> compression, it should be possible to do this without a database.
> >>
> >> How? If you shorten URLs, you have to be able to reconstruct the
> >> long ones. Compression can't do that to arbitrary lengths.
> >> Somewhere there needs to be the rest of the information.
> >
> > First of all, you quoted me out of context.
>
> I trimmed the context. You got a problem with that?
>
> > Second, do you even read what you reply to?  See the markings above.
>
> Instead of thinking about URL shorteners specifically, think generally
> about information theory. You cannot, fundamentally, shorten all URLs
> arbitrarily. There just isn't enough room to store the information.
>
> > And as for second-level domains, consider for example “t.c” instead
> > of “twitter.com” as part of the short URI.
>
> That'll work only for the ones that you code in specifically, and
> that's only shortening your URL by 8 characters. A typical URL needing
> shortening is over 80 characters - maybe several hundred. You need to
> cut that down to a manageable length. That fundamentally cannot be
> reversed without readding information.

And I submit that putting someone in charge of the drives organization, 
and the database on that drive that the url has to dig thru, can make a 
huge difference in the length of the resultant url.

> >>> And with the exception of Twitter-ish sites that place a limit on
> >>> message length, there really is *no need* for shorter URIs
> >>> nowadays.  (HTTP) clients and servers are capable of processing
> >>> really long ones [1]; electronic communications media and related
> >>> software, too [2].  And data storage space as well as data
> >>> transmission has become exceptionally inexpensive.  A few less
> >>> bytes there do not count.

They may not count for that much in terms of what the user pays for 
bandwidth, but see below.  And some users are probably still paying for 
their internet access by the minute in some locales.

> >> There are many places where there are limits (hard or soft) on
> >> message lengths. Some of us still use MUDs and 80-character line
> >> limits.
> >
> > See above.  Covered by [2].
>
> Unrelated. Not covered by that link. Go use a MUD some time.
>
> > But speaking of length limits, the lines in your postings are too
> > long, according to Usenet convention.  I had to correct the
> > quotations so that they remained readable when word-wrapped.
>
> Oh, so you'd rather the lines be cut to... I dunno, 80 characters?
> Might be a good reason to use a URL shortener.
>
usenet generally encourages us to set our word wrap at 72 to 73 
characters so there is room for the invitable additions of the quote > 
character so we can track who said what.  That is just common good 
practice.

> >> Business cards or other printed media need to be transcribed by
> >> hand. Dictation of URLs becomes virtually impossible when they're
> >> arbitrarily long.

OTOH, url's in excess of 250 characters long exist only to polish ego's 
of the people involved or demonstrate that they could not organize a 
company picnic in a 4 person company.

Few enough recognize that problem and post their urls on the form of 
<url> which most email agents recognize as a url, that before 
presentation to a browser when you click on it, will then go thru it, 
stripping out the line feeds and carriage returns so that the original 
as pasted and wrecked by the emailers word wrapping, is restored and it 
has at least a snowballs chance in hell of working.

But you can't teach a winderz user to do that any better than you can 
break them from top posting.

> > (You are not reading at all, are you?)  This is covered by that:
> >>> Instead, there *is* a need for *concise*, *semantic* URIs that Web
> >>> (service) users can *easily* *remember*.  It is the duty of the
> >>> original Web authors∕developers to make sure that there are, and I
> >>> think that no kind of automation is going to ease or replace
> >>> thoughtful path design anytime soon (but please, prove me wrong):
> >>
> >> Sure...... if you control the destination server. What if you're
> >> engaging in scholarly discussion about someone else's content? You
> >> can't change the canonical URLs, and you can't simply copy their
> >> content to your own server (either for licensing reasons or to
> >> guarantee that the official version hasn't been tampered with).
> >
> > That is why I said it is the duty of the original
> > authors/developers.  It is a community effort, and it is not going
> > to happen overnight.  But evading the problem with unreliable
> > replacements such as “short URLs” is not going to solve it either.

True, its fixing the wrong end of the problem.

> So, you can go fight an unwinnable battle against literally every web
> creator in the world. Meanwhile, I'll keep on using URL shorteners.
>
> ChrisA

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#104982

Gene Heskett wrote:

> On Tuesday 15 March 2016 19:55:52 Chris Angelico wrote:
>> On Wed, Mar 16, 2016 at 10:38 AM, Thomas 'PointedEars' Lahn
>> > And as for second-level domains, consider for example “t.c” instead
>> > of “twitter.com” as part of the short URI.
>> That'll work only for the ones that you code in specifically, and
>> that's only shortening your URL by 8 characters. A typical URL needing
>> shortening is over 80 characters - maybe several hundred. You need to
>> cut that down to a manageable length. That fundamentally cannot be
>> reversed without readding information.
> 
> And I submit that putting someone in charge of the drives organization,
> and the database on that drive that the url has to dig thru, can make a
> huge difference in the length of the resultant url.

Maybe it’s just the late/early hour, but you’ve just lost me.
Please elaborate.
 
>> >>> And with the exception of Twitter-ish sites that place a limit on
>> >>> message length, there really is *no need* for shorter URIs
>> >>> nowadays.  (HTTP) clients and servers are capable of processing
>> >>> really long ones [1]; electronic communications media and related
>> >>> software, too [2].  And data storage space as well as data
>> >>> transmission has become exceptionally inexpensive.  A few less
>> >>> bytes there do not count.
> 
> They may not count for that much in terms of what the user pays for
> bandwidth, but see below.  And some users are probably still paying for
> their internet access by the minute in some locales.

So they should loathe more the overhead measured in *kibibytes* and delay 
measured in *seconds* caused by additional HTTP requests due to redirection 
from “short URLs” than the few more *bytes* in longer, original URLs, yes?
 
-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#104984

On Tuesday 15 March 2016 22:46:44 Thomas 'PointedEars' Lahn wrote:

> Gene Heskett wrote:
> > On Tuesday 15 March 2016 19:55:52 Chris Angelico wrote:
> >> On Wed, Mar 16, 2016 at 10:38 AM, Thomas 'PointedEars' Lahn
> >>
> >> > And as for second-level domains, consider for example “t.c”
> >> > instead of “twitter.com” as part of the short URI.
> >>
> >> That'll work only for the ones that you code in specifically, and
> >> that's only shortening your URL by 8 characters. A typical URL
> >> needing shortening is over 80 characters - maybe several hundred.
> >> You need to cut that down to a manageable length. That
> >> fundamentally cannot be reversed without readding information.
> >
> > And I submit that putting someone in charge of the drives
> > organization, and the database on that drive that the url has to dig
> > thru, can make a huge difference in the length of the resultant url.
>
> Maybe it’s just the late/early hour, but you’ve just lost me.
> Please elaborate.
>
Elaborate? Unless the database is expected to handle the whole human 
race, what 9 billion of us?, a subdir name longer than 8 chars is wasted 
space.  And we regularly see them much longer that that, with a friggin 
regex in the middle, using 6 to 15 subdirs if what I read is broken 
down. Thats assinine IMO, and if because they cannot do it right for a 
platform other than windows, it doesn't work for me, then I don't care 
if it links to the g-code (RS-274-D) that would make my machines carve 
me a key to Fort Knox.  If these ID10T's want me to see whatever the 
heck it is they're are peddling to make me last all night, they WILL fix 
it.  Heck, at 81, and diabetic for almost 30 years, nothing they can 
sell me will fix it anyway. :(
> >> >>> And with the exception of Twitter-ish sites that place a limit
> >> >>> on message length, there really is *no need* for shorter URIs
> >> >>> nowadays.  (HTTP) clients and servers are capable of processing
> >> >>> really long ones [1]; electronic communications media and
> >> >>> related software, too [2].  And data storage space as well as
> >> >>> data transmission has become exceptionally inexpensive.  A few
> >> >>> less bytes there do not count.
> >
> > They may not count for that much in terms of what the user pays for
> > bandwidth, but see below.  And some users are probably still paying
> > for their internet access by the minute in some locales.
>
> So they should loathe more the overhead measured in *kibibytes* and
> delay measured in *seconds* caused by additional HTTP requests due to
> redirection from “short URLs” than the few more *bytes* in longer,
> original URLs, yes?
>
> --
> PointedEars
>
> Twitter: @PointedEars2
> Please do not cc me. / Bitte keine Kopien per E-Mail.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#104990

On Wednesday 16 March 2016 10:38, Thomas 'PointedEars' Lahn wrote:

> Chris Angelico wrote:
> 
>> On Wed, Mar 16, 2016 at 9:53 AM, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
> 
> Attribution *line*, not attribution novel.

Chris' attribution is about 75,000 words short of even a small novel.

And it would comfortably fit on a single line if not for your insistence on 
using a non-real (pretend) name:

"On Wed, Mar 16, 2016 at 9:53 AM, Thomas Lahn <PointedEars@web.de> wrote:"

Given how often you tell people off for not using "real names", I don't 
understand why you do the same thing.



-- 
Steve

[toc] | [prev] | [next] | [standalone]

#104988

Chris Angelico wrote:
> There are many places where there are limits (hard or soft) on message
> lengths. Some of us still use MUDs and 80-character line limits.
> Business cards or other printed media need to be transcribed by hand.
> Dictation of URLs becomes virtually impossible when they're
> arbitrarily long.

Your typical shortened URL made up of a random jumble
of letters and numbers isn't good for dictating or
transcribing from a business card either.

For those uses, a well-chosen semantically-memorable
URL is still the best solution. There shouldn't be
too much trouble in arranging one of those that's
short enough to put on a business card.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#104989

On Wed, Mar 16, 2016 at 3:27 PM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Chris Angelico wrote:
>>
>> There are many places where there are limits (hard or soft) on message
>> lengths. Some of us still use MUDs and 80-character line limits.
>> Business cards or other printed media need to be transcribed by hand.
>> Dictation of URLs becomes virtually impossible when they're
>> arbitrarily long.
>
>
> Your typical shortened URL made up of a random jumble
> of letters and numbers isn't good for dictating or
> transcribing from a business card either.
>
> For those uses, a well-chosen semantically-memorable
> URL is still the best solution. There shouldn't be
> too much trouble in arranging one of those that's
> short enough to put on a business card.

Quite a few URL shorteners allow you to pick a keyword (conditionally
on it not being in use, of course). For example,
http://bit.ly/threshvote is perfectly memorable, but is still shorter
than the address it redirects to. Given that it's a mobile app
download link, it's extremely helpful for people to be able to type
that without clicking on it; and since it's going to the Google Play
Store, the creator of the app has no power to shorten the official
URL.

In some cases, the correct solution would be a short URL at a domain
that the provider controls. But that's no different from running your
own shortener service - it still has the extra indirection and
consequent risks. So for a lot of people, a public shortener is just
as good.

ChrisA

[toc] | [prev] | [next] | [standalone]

#105136

Chris Angelico wrote:

> In some cases, the correct solution would be a short URL at a domain
> that the provider controls. But that's no different from running your
> own shortener service - it still has the extra indirection and
> consequent risks. So for a lot of people, a public shortener is just
> as good.

A domain that the provider controls is different: It reduces the risk
of the shorter URL breaking because there is only one stakeholder.

BTW and JFTR, this thread has gone *way* off topic.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#105144

On Thursday, March 17, 2016 at 1:28:05 PM UTC-5, Thomas 'PointedEars' Lahn wrote:

> BTW and JFTR, this thread has gone *way* off topic.

Who cares? Python-list is not a "strictly moderated group". So long as the discussion is informative, or heck, even entertaining, no crime has been committed. Many *WILDLY* diverse topics have been discussed here, and i believe, the community is better for it! Sure, places where strict CoC are enforced, and "narrow topic paths" are clearly defined, can be beneficial, but this list is *NOT* one of them. Every community needs an area where all are welcome to participate in an environment where rules and regulations are not onerous. While spam is *NEVER* tolerated, "slight flaming" and "limited trolling" is. It's too easy to become a totalitarian when you have unlimited power to ban. From time to time, every one of us needs to climb down from our ivory towers and venture into the "seedy side" of town, if for nothing more, that to be reminded of how unrighteous we really are. Have you ever stopped and spoken with a homeless person? You'd be surprised how humble, and even highly intelligent, some of them can be! Diversity *MUST* have a place to exist in every community. *EVERY* member deserves an audience. 

[toc] | [prev] | [next] | [standalone]

#105152

Rick Johnson wrote:

> On Thursday, March 17, 2016 at 1:28:05 PM UTC-5, Thomas 'PointedEars' Lahn
> wrote:
> 
>> BTW and JFTR, this thread has gone *way* off topic.
   ^^^^^^^^^^^^ 
> Who cares? Python-list is not a "strictly moderated group". [rant]

Get a life, *please*.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#105177

On Thursday, March 17, 2016 at 4:15:37 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
 
> Get a life, *please*.

Well, you see *Thomas*, the problem is, this *IS* my life! I couldn't remove myself from this life anymore than you could apply a Bézier curve to your upper auricles -- we just wouldn't be same anymore!

[toc] | [prev] | [next] | [standalone]

#105268

Rick Johnson wrote:

> On Thursday, March 17, 2016 at 4:15:37 PM UTC-5, Thomas 'PointedEars' Lahn
> wrote:
>> Get a life, *please*.
> 
> Well, you see *Thomas*, the problem is, this *IS* my life! I couldn't
> remove myself from this life anymore than you could apply a Bézier curve
> to your upper auricles -- we just wouldn't be same anymore!

AIUI, “Get a life” means that the person so addressed should not make a fuss 
about insignificant things.  Like posting a 16-line rant (provided that it 
would be properly line-broken according to Usenet convention, which it was 
not) as response to a one-line statement that was even prepended with “BTW 
and JFTR” (“by the way and just for the record”) to indicate its 
insignificance to its author.

If it were your life to make a fuss about such things in this way, you would 
have my sympathy, but I would have to reconsider whether your postings are 
worth reading anymore.

HTH (hope that helps)

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#104964

On Tuesday, March 15, 2016 at 5:54:46 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
> Vinicius Mesel wrote:
> > I'm a 16 year old Python Programmer that wanted to do
> > something different. But, like we know, ideas are quite
> > difficult to find. So I decided to develop a URL
> > Shortener to help the Python community out and share my
> > coding knowledge, and today the project was launched
> > with its first stable version.

Although Thomas makes some very valid points, don't let
anybody discourage you Vinicius. If you want to build
something, and everyone in the *ENTIRE* world say's it's a bad
idea, do it anyway -- if for nothing else than to spite
them. :-P

> While I commend your efforts, I think that you should have
> chosen another topic for your project.  It is also hard
> for me to see in which way this is "something different" -
> are there not enough "URL Shorteners" already? -, and how
> a "URL Shortener" could "help the Python community out".

How many Python URL trimmers are there anyway? If none
exist, then he could claim the "i was the first" prize. If
others already exist, no harm, perhaps his implementation
utilizes a unique method of creating these small URLs that
could be a valuable teaching tool. And even if none of these
apply, his contribution is most welcome -- this is an open
community after all.

> Because I think that "URL Shorteners" are a bad idea in
> the first place: One never knows for how long a time a
> "short URL" works, who is listening in the middle, and
> what they are referring to, until one uses them at which
> point it is too late.  If a "short URL" expires, there is
> *no way* to retrieve the referred content; when a *real*
> URI breaks, there are services like the Internet Archive
> and the Google cache to help one out.  So when I see a
> "short URL", I tend not to use it.

I'll have to agree with Thomas here. I avoid them like the
plague for the same reasons. But don't be discouraged by
this, Vinicius, many people use them. Thankfully, not
everyone is as paranoid as Thomas and myself. :-)

[toc] | [prev] | [next] | [standalone]

#104972

Rick Johnson wrote:

> On Tuesday, March 15, 2016 at 5:54:46 PM UTC-5, Thomas 'PointedEars' Lahn
> wrote:
>> Vinicius Mesel wrote:
>> > I'm a 16 year old Python Programmer that wanted to do
>> > something different. But, like we know, ideas are quite
>> > difficult to find. So I decided to develop a URL
>> > Shortener to help the Python community out and share my
>> > coding knowledge, and today the project was launched
>> > with its first stable version.
> 
> Although Thomas makes some very valid points, don't let
> anybody discourage you Vinicius. If you want to build
> something, and everyone in the *ENTIRE* world say's it's a bad
> idea, do it anyway -- if for nothing else than to spite
> them. :-P

You are giving bad advice to a junior developer, advising them to *waste* 
*their* *youth* developing for the recycle bin.  It can no doubt be 
educational to play with programming.  But if actually the *entire* world 
says a it is a bad idea, then it probably is.  Unfortunately, there is 
prevailing the common misconception of the misunderstood genius, and that a 
real genius would sink so low as to do things just in order to prove 
everybody wrong.  But to do so is not genial, it is outright stupid.  
Because what if it does not work out in the end?

Instead, they should find out what problems people have, and what kind of 
software people *really* and *desperately* *need* to solve them, and *then* 
go for it no matter what other people who are not in need say.  Often the 
people that desperately need something solved are close; in fact, it is very 
likely that the first person that really needs something solved is oneself.

For example, what really got me into programming was that I was tired of 
typing commands to run my favorite DOS games, so I learned batch file 
programming to write myself a menu to start them if they were in the paths 
where I expected them to be.  Being limited by the shortcomings of that 
language, I learned Turbo Pascal to search for the games, and in doing that 
I learned a lot of other things that I had never thought of before (like 
creating GUIs, and mouse pointers with embedded Assembler code, and OOP).  
And so on, eventually to Python (IIRC, the second-last programming language 
that I learned).

Want a more prominent example?  Linus Torvalds wrote a kernel for an 
operating system because, although it started his fascination for operating 
systems, MINIX did not suffice for *him*; only later he announced *on 
Usenet* (comp.os.minix) what would become the Linux kernel, and look what 
arose from that.  Because the people he announced it to thought, “Hey, that 
could be really *useful*!”.
 
-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web