'google' 2

[tatata9999]

The first generation of web site search engine hands-down is google.
A majority of these web
sites are static page -driven html pages.

Now, I would think more and more web-based applications are coming
into the fray, my recent
experience with google's webbot (indexing engine, a part of the
google's search service) tells
me that its indexing algorithm does not consider a database-driven web
application as part of
a qualified 'web site'. Minicking it as a html site is like a man
trying to dress in skirt,
oh, my poor Scotsman... Hence, I believe a service that would evaluate
and index web apps
(database-driven, xml-based or what not) vs. the plain HTML -driven
web sites would be
valuable to both consumers and businesses. Or maybe there's already
such a service out there?

[David Quinton]

On Sun, 21 Oct 2007 02:38:47 -0000, ta********@gmail.com wrote:

Please take a look at my app to see what I mean, http://www.mytata.net
when you have a chance. So, in sum, the speed of the app is a major
design consideration.

Not criticising, but:
<http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fweb.mytata.net%3A 8000%2FmyTA%2F>
won't help.
--
Locate your Mobile phone: <http://www.bizorg.co.uk/news.html>
Great gifts: <http://www.ThisBritain.com/ASOS_popup.html>

[Andy Dingley]

On 21 Oct, 03:38, [e-mail] wrote:

On Oct 20, 7:20 pm, Adrienne Boswell <[e-mail]:

2. Put CSS in an external stylesheet.
3. Put javascript in an external script.

Yes, I read about using include file for js, so, I just did.

Which is the complete opposite of what you were told

As for CSS, I've even eliminated them for now for speed sake.

You're mad, aren't you?

[André Gillibert]

ta********@gmail.com wrote:

Now, I would think more and more web-based applications are coming into
the fray, my recent experience with google's webbot (indexing engine, a
part of the google's search service) tells me that its indexing
algorithm does not consider a database-driven web application as part of
a qualified 'web site'.

Google doesn't index your "database" pages because you didn't provide a
public access!
Otherwise, google has perfectly fine algorithms to crawl database driven
sites.
For google indexing, keep in mind that AJAX is very unfriendly to bots
(and to people who have a good browser).

As for CSS, I've even eliminated them for now for speed sake.

POSH (Plain Old Semantic HTML) visually improved by a stylesheet results
in much smaller code than table driven HTML code designed with its layout
in mind only.

Your code is not optimized.
For example, this page:
http://web.mytata.net:8000/myTA/index2_so.cfm?utype=s
Uses 6819 bytes.
It could get down to 600 bytes (you would have to remove that JavaScript
thing).

As for images, I have only a few tiny ones.

That's ok.

One thing I want to do away is a bit too many tables.

Table layouts are a bad thing.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

[Beauregard T. Shagnasty]

André Gillibert wrote:

It could get down to 600 bytes (you would have to remove that
JavaScript thing).

Do you mean the 22,050 bytes of urchintracker.js ? :-)

--
-bts
-Motorcycles defy gravity; cars just suck

[André Gillibert]

Beauregard T. Shagnasty wrote:

André Gillibert wrote:

>It could get down to 600 bytes (you would have to remove that
JavaScript thing).

Do you mean the 22,050 bytes of urchintracker.js ? :-)

The 217 bytes of toggle.js, the 21411 bytes of urchin.js, and #6000 bytes
of useless/invisible tag soup.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

[tatata9999]

On Oct 21, 9:04 am, "André Gillibert"
<[e-mail]:

[e-mail] wrote:

Now, I would think more and more web-based applications are coming into
the fray, my recent experience with google's webbot (indexing engine, a
part of the google's search service) tells me that its indexing
algorithm does not consider a database-driven web application as part of
a qualified 'web site'.

Google doesn't index your "database" pages because you didn't provide a
public access!
Otherwise, google has perfectly fine algorithms to crawl database driven
sites.
For google indexing, keep in mind that AJAX is very unfriendly to bots
(and to people who have a good browser).

As for CSS, I've even eliminated them for now for speed sake.

POSH (Plain Old Semantic HTML) visually improved by a stylesheet results
in much smaller code than table driven HTML code designed with its layout
in mind only.

Your code is not optimized.
For example, this page:http://web.mytata.net:8000/myTA/index2_so.cfm?utype=s
Uses 6819 bytes.
It could get down to 600 bytes (you would have to remove that JavaScript
thing).

As for images, I have only a few tiny ones.

That's ok.

One thing I want to do away is a bit too many tables.

Table layouts are a bad thing.

--
If you've a question that doesn't belong to Usenet, contact me at
<[e-mail]>

On providing public access to google for indexing my database, could
you elaborate a bit?
Like usually it's done via sitemap.xml? or?
Then, what I should watch in terms of privacy for user data protection
(though I tend to think the only confidential data in my db would be
user email address, could I set up some sort of exclusion rule?)
How that thing work, I'd loving to know it NOW.

And thank you for the technique on POSH and CSS combo. Will work on
it...

[tatata9999]

On Oct 21, 2:52 am, David Quinton
<[e-mail] :

On Sun, 21 Oct 2007 02:38:47 -0000, [e-mail] wrote:

Please take a look at my app to see what I mean,http://www.mytata.net
when you have a chance. So, in sum, the speed of the app is a major
design consideration.

Not criticising, but:
<http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fweb.mytata.n...>
won't help.
--
Locate your Mobile phone: <http://www.bizorg.co.uk/news.html>
Great gifts: <http://www.ThisBritain.com/ASOS_popup.html>

I don't perceive it as criticism at all, on the contrary, I want to
thank you, someting on the plate...

[tatata9999]

On Oct 21, 8:16 am, Andy Dingley <[e-mail]:

On 21 Oct, 03:38, [e-mail] wrote:

On Oct 20, 7:20 pm, Adrienne Boswell <[e-mail]:

2. Put CSS in an external stylesheet.
3. Put javascript in an external script.

Yes, I read about using include file for js, so, I just did.

Which is the complete opposite of what you were told

You lost me here.

>

As for CSS, I've even eliminated them for now for speed sake.

You're mad, aren't you?

You're right, I don't see its syntax's logic (not from a designer's
background).

[tatata9999]

On Oct 21, 9:40 am, "Beauregard T. Shagnasty"
<[e-mail]:

André Gillibert wrote:

It could get down to 600 bytes (you would have to remove that
JavaScript thing).

Do you mean the 22,050 bytes of urchintracker.js ? :-)

--
-bts
-Motorcycles defy gravity; cars just suck

The tradeoff of not knowing site usage would be huge unless spending
time to find an alternative, have to chew on that.

[tatata9999]

On Oct 21, 9:46 am, "André Gillibert"
<[e-mail]:

Beauregard T. Shagnasty wrote:

André Gillibert wrote:

It could get down to 600 bytes (you would have to remove that
JavaScript thing).

Do you mean the 22,050 bytes of urchintracker.js ? :-)

The 217 bytes of toggle.js, the 21411 bytes of urchin.js, and #6000 bytes
of useless/invisible tag soup.

--
If you've a question that doesn't belong to Usenet, contact me at
<[e-mail]>

I respectfully disagree on not using invisible tag (to me, providing
user less cluttered page would easier for consumption...)

[André Gillibert]

wrote:

On Oct 21, 9:46 am, "André Gillibert"
<[e-mail]:

>Beauregard T. Shagnasty wrote:

André Gillibert wrote:

>It could get down to 600 bytes (you would have to remove that
JavaScript thing).

Do you mean the 22,050 bytes of urchintracker.js ? :-)

The 217 bytes of toggle.js, the 21411 bytes of urchin.js, and #6000
bytes
of useless/invisible tag soup.

I respectfully disagree on not using invisible tag (to me, providing
user less cluttered page would easier for consumption...)

My point was to REMOVE entirely the invisible content from the page and to
replace the JavaScript link with a regular anchor pointing to a page with
the content.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

[tatata9999]

On Oct 21, 11:35 am, "André Gillibert"
<[e-mail]:

wrote:

On Oct 21, 9:46 am, "André Gillibert"
<[e-mail]:

Beauregard T. Shagnasty wrote:
André Gillibert wrote:

It could get down to 600 bytes (you would have to remove that
JavaScript thing).

Do you mean the 22,050 bytes of urchintracker.js ? :-)

The 217 bytes of toggle.js, the 21411 bytes of urchin.js, and #6000
bytes
of useless/invisible tag soup.

I respectfully disagree on not using invisible tag (to me, providing
user less cluttered page would easier for consumption...)

My point was to REMOVE entirely the invisible content from the page and to
replace the JavaScript link with a regular anchor pointing to a page with
the content.

--
If you've a question that doesn't belong to Usenet, contact me at
<[e-mail]>- Hide quoted text -

- Show quoted text -

Does this have something to do with google bot indexing? Or saving
some bytes? thks. oh, could you share your knowledge on the google
database indexing techniques? Many thks.

[André Gillibert]

ta********@gmail.com wrote:

On Oct 21, 9:40 am, "Beauregard T. Shagnasty"
<[e-mail]:

>André Gillibert wrote:

It could get down to 600 bytes (you would have to remove that
JavaScript thing).

Do you mean the 22,050 bytes of urchintracker.js ? :-)

The tradeoff of not knowing site usage would be huge unless spending
time to find an alternative, have to chew on that.

Do your statistics with *your* server. HTTP requests are sent to your
server, I don't see why you wouldn't be able to make statistics on them?
You can get the client IP address, all the HTTP headers such as the user
agent string or the referer URI, without any client-side scripts.

This type of script make me confirm that JavaScripts are mainly used as
spywares, not for user benefit.
I understand that kind people who use JavaScript for improving user
experience defends their JavaScripts. But I don't understand how people
who use JavaScripts only to "own" the user computer can defend their
position.
Assume that 100% of the JavaScripts on earth were used for such cr*p, as a
*user*, would you really enable them in your browser profile?

Fortunately, I've disabled JavaScripts on my browser. Surely, it breaks
your statistics, but web statistics are always biaised.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

[tatata9999]

On Oct 21, 11:51 am, "André Gillibert"
<[e-mail]:

[e-mail] wrote:

On Oct 21, 9:40 am, "Beauregard T. Shagnasty"
<[e-mail]:

André Gillibert wrote:
It could get down to 600 bytes (you would have to remove that
JavaScript thing).

Do you mean the 22,050 bytes of urchintracker.js ? :-)

The tradeoff of not knowing site usage would be huge unless spending
time to find an alternative, have to chew on that.

Do your statistics with *your* server. HTTP requests are sent to your
server, I don't see why you wouldn't be able to make statistics on them?
You can get the client IP address, all the HTTP headers such as the user
agent string or the referer URI, without any client-side scripts.

This type of script make me confirm that JavaScripts are mainly used as
spywares, not for user benefit.
I understand that kind people who use JavaScript for improving user
experience defends their JavaScripts. But I don't understand how people
who use JavaScripts only to "own" the user computer can defend their
position.
Assume that 100% of the JavaScripts on earth were used for such cr*p, as a
*user*, would you really enable them in your browser profile?

Fortunately, I've disabled JavaScripts on my browser. Surely, it breaks
your statistics, but web statistics are always biaised.

--
If you've a question that doesn't belong to Usenet, contact me at
<[e-mail]>

Thank you very much. I see your point. Not really into CSS, is
there a way to 'minik' javascript function like toggle in my case with
CSS?

[Beauregard T. Shagnasty]

ta********@gmail.com wrote:

"Beauregard T. Shagnasty" wrote:

>André Gillibert wrote:

>>It could get down to 600 bytes (you would have to remove that
JavaScript thing).

Do you mean the 22,050 bytes of urchintracker.js ? :-)

The tradeoff of not knowing site usage would be huge unless spending
time to find an alternative, have to chew on that.

Your urchintracker did not register me when I visited your page. All the
google ads, google-analytics and urchin domains are in my HOSTS file.
However, your web host will have registered that I made requests to your
page.

--
-bts
-Motorcycles defy gravity; cars just suck

[tatata9999]

On Oct 21, 12:38 pm, "Beauregard T. Shagnasty"
<[e-mail]:

[e-mail] wrote:

"Beauregard T. Shagnasty" wrote:

André Gillibert wrote:
It could get down to 600 bytes (you would have to remove that
JavaScript thing).

Do you mean the 22,050 bytes of urchintracker.js ? :-)

The tradeoff of not knowing site usage would be huge unless spending
time to find an alternative, have to chew on that.

Your urchintracker did not register me when I visited your page. All the
google ads, google-analytics and urchin domains are in my HOSTS file.
However, your web host will have registered that I made requests to your
page.

--
-bts
-Motorcycles defy gravity; cars just suck

Yes, I know my web server has a log for user agent requests.
Initially I'll just read the plain log file, then find a tool that
organizes data for me. Thks.

[Harlan Messinger]

ta********@gmail.com wrote:

The first generation of web site search engine hands-down is google.
A majority of these web
sites are static page -driven html pages.

Now, I would think more and more web-based applications are coming
into the fray, my recent
experience with google's webbot (indexing engine, a part of the
google's search service) tells
me that its indexing algorithm does not consider a database-driven web
application as part of
a qualified 'web site'.

It does, but whether you get results depends on your URLs. If links to a
particular page always have the URL

http://example.com/generate.aspx?page=472

then Google should handle it as well as

http://example.com/staticURL.aspx

But take the case of Amazon, where successive searches produced the
following URLs for me for the same album:

http://www.amazon.com/Cant-Imagine-M...3066211&sr=8-2

http://www.amazon.com/Cant-Imagine-M...3066264&sr=1-2

http://www.amazon.com/Cant-Imagine-M...3066274&sr=1-7

because Amazon includes session-specific information in the query string
(such as the query ID [qid]) and the position of the item in the search
results from which it was selected and the page encoding. Google will
come across each of these links exactly once, and never have any idea
that they represent the same album. So if Amazon didn't also produce a
unique canonical URL for each article to feed to the search engines,
Amazon items couldn't be effectively indexed and ranked. (Well, I
suspect Amazon actually has a special arrangement for feeding Google,
but that doesn't alter my point.)

[tatata9999]

On Oct 22, 11:23 am, Harlan Messinger
<[e-mail]:

[e-mail] wrote:

The first generation of web site search engine hands-down is google.
A majority of these web
sites are static page -driven html pages.

Now, I would think more and more web-based applications are coming
into the fray, my recent
experience with google's webbot (indexing engine, a part of the
google's search service) tells
me that its indexing algorithm does not consider a database-driven web
application as part of
a qualified 'web site'.

It does, but whether you get results depends on your URLs. If links to a
particular page always have the URL

http://example.com/generate.aspx?page=472

then Google should handle it as well as

http://example.com/staticURL.aspx

But take the case of Amazon, where successive searches produced the
following URLs for me for the same album:

http://www.amazon.com/Cant-Imagine-M...B000AMU0UI/ref...

http://www.amazon.com/Cant-Imagine-M...B000AMU0UI/ref...

http://www.amazon.com/Cant-Imagine-M...B000AMU0UI/ref...

because Amazon includes session-specific information in the query string
(such as the query ID [qid]) and the position of the item in the search
results from which it was selected and the page encoding. Google will
come across each of these links exactly once, and never have any idea
that they represent the same album. So if Amazon didn't also produce a
unique canonical URL for each article to feed to the search engines,
Amazon items couldn't be effectively indexed and ranked. (Well, I
suspect Amazon actually has a special arrangement for feeding Google,
but that doesn't alter my point.)

But the thing is, my web app requires user account, so, probably I'll
have to create some gimick url like
http://www.mytata.net/SupportBotQuery?qid=1234 something?

btw, could you folks try my site, http://www.mytata.net/ ? I was told
it's not accessable about 10 minutes ago (my apologies for having to
post this particular request)

Thanks.

[André Gillibert]

ta********@gmail.com wrote:

On providing public access to google for indexing my database, could
you elaborate a bit?

The user specific data (e.g. activity tables) is private. It's only
accessible when logged in.
This ensures privacy of the data, but prevents (thanks goodness) google
from crawling this data. Similarly, google doesn't access to your bank
account!
This is a Good Thing(TM).

Just keep it as it is. Google can still access the public pages (e.g. the
home page), but won't access to user's private data.

Like usually it's done via sitemap.xml?

Forget about sitemap.xml; It is useless as far as every page in your site
is accessible through regular anchors. sitemap.xml is useful for databases
for which there're no HTML indexes, but only a search feature.

--
If you've a question that doesn't belong to Usenet, contact me at
<ta*****************@yahoDELETETHATo.fr>

[tatata9999]

On Oct 22, 6:16 pm, "André Gillibert"
<[e-mail]:

[e-mail] wrote:

On providing public access to google for indexing my database, could
you elaborate a bit?

The user specific data (e.g. activity tables) is private. It's only
accessible when logged in.
This ensures privacy of the data, but prevents (thanks goodness) google
from crawling this data. Similarly, google doesn't access to your bank
account!
This is a Good Thing(TM).

Just keep it as it is. Google can still access the public pages (e.g. the
home page), but won't access to user's private data.

Like usually it's done via sitemap.xml?

Forget about sitemap.xml; It is useless as far as every page in your site
is accessible through regular anchors. sitemap.xml is useful for databases
for which there're no HTML indexes, but only a search feature.

--
If you've a question that doesn't belong to Usenet, contact me at
<[e-mail]>

Ok, thank you.