-Original Message-
>> From: Bill Stephenson
>> Sent: Feb 21, 2010 4:19 PM
>> To: Perl MacOSX
>> Subject: Web Apps
>>
>> I started playing with iPhone/iTouch/iPad "web apps" just last week.
>>
>> http://developer.apple.com/safari/lib
4:19 PM
>To: Perl MacOSX
>Subject: Web Apps
>
>I started playing with iPhone/iTouch/iPad "web apps" just last week.
>
>http://developer.apple.com/safari/library/navigation/
>index.html#section=Resource%20Types&topic=Coding%20How-Tos
>
>Apple has made it i
I started playing with iPhone/iTouch/iPad "web apps" just last week.
http://developer.apple.com/safari/library/navigation/
index.html#section=Resource%20Types&topic=Coding%20How-Tos
Apple has made it incredibly easy to create a web app that runs exactly
like a native app on
XML vs. SQL hmm.
It's worth recalling *one of* the rationales behind XML: When bytes
were expensive, machine to machine communication especially across
company boundaries (read EDI) couldn't afford to be self-documenting.
Huge binders of ANSI EDI specifications were required to correctly
parse
On 6 Feb 2004, at 02:37 pm, Chris Devers wrote:
Anyway, it was pointed out to me in a different offlist response that I
was probably answering the wrong question. Oh well -- it still seems
like
a useful (and under-publicized?) capability of the standard MySQL
client,
so maybe bringing it up will
On Fri, 6 Feb 2004, Rick Measham wrote:
> On 6 Feb 2004, at 01:47 pm, Rick Measham wrote:
> > Thanks Christ,
>
> erm .. sorry .. chris ..
Heh... :)
Anyway, it was pointed out to me in a different offlist response that I
was probably answering the wrong question. Oh well -- it still seems like
a
On 6 Feb 2004, at 01:47 pm, Rick Measham wrote:
Thanks Christ,
erm .. sorry .. chris ..
Rick Measham
Senior Designer and Developer
Printaform Pty Ltd
Tel: (03) 9850 3255
Fax: (03) 9850 3277
http://www.printaform.com.au
http://www.printsupply.com.au
vcard: http://www.printaform.com.au/staff/rickm.v
On Wed, 4 Feb 2004, Rick Measham wrote:
I'd love to see an XML parser embedded into SQL so that I can have:
CREATE TABLE aTable (id serial, data XML);
On 5 Feb 2004, at 05:21 pm, Chris Devers replied:
Does this help?
snip
Is this along the lines of what you were hoping for?
Thanks Christ, but no
On Wed, 4 Feb 2004, Rick Measham wrote:
> I'd love to see an XML parser embedded into SQL so that I can have:
> CREATE TABLE aTable (id serial, data XML);
Does this help?
% mysqldump --help | grep -i ml
-X, --xml Dump a database as well formed XML.
% mysql --help | gre
I can give a longer reply later, but it's my birthday and I'm about to go
out for a late breakfast & a movie :)
On Wed, 4 Feb 2004, Bill Stephenson wrote:
> Chris, you've almost convinced me, but I have to ask, is it really so
> inefficient to search through one directory with 5000 sub-director
Ian Ragsdale wrote:
On Feb 4, 2004, at 1:59 AM, Bill Stephenson wrote:
The above are some of the excuses I've come up with to avoid spending
more time learning stuff. If I'm deluded, it's because I have boxes
upon boxes of software that doesn't work anymore and time invested in
each of them. It
I've worked with both solutions and would like to say first off that it will
take you longer to implement a solid XML solution versus the MySQL solution.
The point made by others is indexing and retrieving records based on
indexes. You would rather say "Get 'bobs' record" Then "flip through all of
On Feb 4, 2004, at 1:59 AM, Bill Stephenson wrote:
It occurs to me that the unix os is basically a database in and of
itself and perl interacts directly with the os, therefore, using it to
store and retrieve data may not be that inefficient.
I agree with this - you can get good results with a we
You've all made great points and I'm sure that I'll follow the advice
given but I'll ask you to indulge me just a bit more.
Chris, you've almost convinced me, but I have to ask, is it really so
inefficient to search through one directory with 5000 sub-directories
to find one that matches the (u
On Tue, 3 Feb 2004, Bill Stephenson wrote:
> If I am building a web app from the ground up, what's the best way to
> deal with storing/retrieving data?
It's not by accident that databases have come to be popular for this kind
of work. Pick one -- MySQL, PostgreSQL, SQLite, or something "real" --
On 4 Feb 2004, at 03:39 pm, kynan wrote:
The idea of having XML in the DB is sound though, if you do it
thoughtfully.
So long as you're not planning on searching on it or indexing it or ...
I once used XML to store information about a webpage as a PostGreSQL
field ... but later down the track I
On 4 Feb 2004, at 03:16 pm, Bill Stephenson wrote:
As computers keep getting faster, and memory and storage cheaper,
isn't it beneficial to program in the most simple, human readable,
least learning required, method?
Never. You're not going to ever read each 2500 user's 2000 x 40kb
records th
Well, I'd vote for MySQL. That amount of hits seems way to heavy to
leave it all to the server.
I guess also it depends a bit on your data and the nature of your
queries too. With MySQL you get the advantages of a relational
database, so you can put your data sources together on the fly by
joi
On Feb 3, 2004, at 10:16 PM, Bill Stephenson wrote:
I'd like to store using XML in a separate text file for each record
created because it's easy and gives me flexibility. I can add data
fields without tweaking tables in a MySQL database. I can add users
easily and keep their data in a separate
If you're busy please forgive me and ignore this, if you have time to
offer an opinion I'd really like to hear from this list on this
subject;
If I am building a web app from the ground up, what's the best way to
deal with storing/retrieving data? For arguments sake let's say the app
will have
20 matches
Mail list logo
