Re: [phplib] default authentication, anyone using it? From: giancarlo pinerolo (giancarlo <email protected>)
Date: 08/05/01

Kristian Koehntopp wrote:
ù
>
> So XML has its purpose and benefit as a data-interchange and
> data-transport format, it is an encapsulation representation of
> data. Such a representation need not be normalized, and need not
> be readily accessible nor does it have to contain integrity
> checking, as such representation is used only in transit and no
> operations are ever performed on it except "export" and
> "import".
>
> But, does an application want to store its internal data in XML
> representation?

When you store something you put it out, kind of export it.
If it is stored also for others to use, why not?

>
> Certainly not.
>
> Does an application want to be able to talk XML or any other
> self-describing format to other applications for that very same
> data?
>
> Sometimes yes.
>
> If the data in question is being shared by many applications,
> and these applications need to be able to work on this data in
> some unsynchronized batch-type fashion, and these applications
> do not need to know of each others existence, XML is the way to
> go. The application we are talking about should be able to dump
> the respective data into some XML format, and be able to
> reimport that XML dump into its internal format, even if it has
> been processed by some other application inbetween.

Processed is a vague definition. Read poses no problem, and this
normally cover a good part of the cases.
Modified by a single user yes, if you write the application on both
sides. And with this you cover most cases, almost all if we are speaking
about user data.
To be modified by many fore sure not, use a db.

> This import
> requires not only parsing, but integrity checking as well, as
> the importing application cannot know if the foreign application
> knew anything about the particular constraints and requirements
> of the importing application. For all the importing application
> knows, the foreign application may even be actively hostile and
> generate bad or unuseable data.

>
> Is XML a generalized mechanism for applications to share live
> data?
>
> No, not at all.
>

To serve yes, though. User data is served, not shared for update.
 
> There is no automatic support for locking and concurrent access.
> XML data is just files.
>

<snip>

>
> So what are the advantages and disadvantages of XMLified User
> data over the current "User" BLOB?
>
> Advantage:
>
> - documented format that is easily parseable by any application
> (as opposed to some PHP program that represents the data and
> which can only be parsed by a PHP parser).

You can invent new data on the fly. This is the biggest advantage.

Think of them as 'data fringes', or 'retail scale accounting'.
Is the stuff in your cart at the supermarket off of any accounting?
Shurely not.
Every evening the cashier electronically connects to Nielsen or wherever
and dumps its information.
On a wholesale scale it is all accounted and structured: so many boxes
left the firm etc.
But the accounting eye follows the article in his path till the last
fringe, when it is sold one by one.

Imagine now that one day you want to apply a discount on certain items
sold at a certain time of the day for those who bought that other item.
And then you want a specific statistical analysis on this 'fringe'. The
boss wants to know how many are selling this way each day... Figure
out how to extend the db and create new fields and tables. The special
offer will only last a week or a month...;-)

We are talking about storing and serving information.
The tables contain definition, prices, weight, how many are left maybe.
Do you want to count also how many are served, at what time, under what
circumstances, discount policies, by whom, sent by whom, what type of
request, in abbination with what other items, and etc?
I can figure out where is the most work is applied to: defining,
defining, defining. Structures to hold information that will never be
updated, because it is more about how it is served, than what it is.

>
> Disadvantages:
>
> - data is still a blob, and one that needs a parser different
> from the builtin PHP parser.
>
> - data cannot be queried natively by any database. There are
> no inexpensive vertical queries on XML data BLOBs.
>
> And what are the advantages and disadvantages of SQLified
> User data over the XMLified BLOB?
>
> Advantages:
>
> - vertical queries are just as efficient as horizonal queries.
> - data can be accessed partially in horizonal and vertical mode
> ("give me just the background color for user x, not all user x
> preferences" is actually possible, as well as "give me the
> average age for all users that have logged in within the
> last 3 weeks.")
>
> Disadvantage:
>
> - SQLified table structure is more rigid. In order to introduce
> a new field you need to change the table structure.
>
> - (without mysqldump): data is not easily exportable in a
> nonpropietary format.
>

> And finally, returning to your argument, I fail to see the
> actual benefit of using XML over a rigid SQL table structure
> given the above ideas and experiences of mine. I still stand by
> design decision:
>
> > > Im my personal opinion User should be replaced by a class that
> > > is not derived from Session or any Session superclass. It should
> > > not use the Session storage mechanism. There should be a User
> > > class that uses a structured table for preferences, and that
> > > allows horizontal and vertical queries,
>
> If you see this as:
>
> > I feel this too rigid
>
> then there should be a mechanism in that class that allows you
> to change the table structure with a single call. Also, you'd
> need at least a command line tool if not a set of methods in the
> class that allow you to export and import data from that User
> table or tables to and from XML.

There is is a practical, reasonable mark for 'consolidated' structures.
Further one must provide the possibility to stitch free form fringes.
They can always become consolidated later, if you see need.
I don't deny the necessity of consolidated structures. But I think that
not to provide for provisional creation of 'unconsolidated', free form,
fringes of information is an error.

Giancarlo 

-- 
Abbestellen mit Mail an:   phplib-unsubscribe <email protected>
Kommandoliste mit Mail an: phplib-help <email protected>