By the way -- is it me, or is the current Import/Export interface
broken? I tried to select multiple objects to export, but I can only
get the first one to actually be exported.
Nope, that's the way it's supposed to work, I think :-)
It's why I got happy when I saw your earlier post; it
Hi Fred,
"Fred" == Fred Wilson Horch [EMAIL PROTECTED] writes:
Fred Wanted to follow up on Steve's points.
Fred I don't know if we need just one serialization interface
Fred that tries to solve all five issues.
Ok..
Fred We currently have two serialization interfaces in
Steve Spicklemire wrote:
Fred FWIW, I'm working on tweaking the XML export/import code to
Fred serialize object hierarchies as directories and files,
Fred rather than exporting a single file.
Cool.. this sounds like a promising approach. I'd be interested
in testing this..
On 26 Mar 2001, Karl Anderson wrote:
Is there a particular set of tools or editing paradigms that we have
in mind when we say that a non-XML representation is suited for client
side tools?
I think the prime current example of this is the way you can use
any text editor to edit the serialized
Hi Steve,
You wrote:
Fred We currently have two serialization interfaces in Zope:
Fred 1) the FTP interface, and 2) the XML export interface.
Hmm.. maybe I'm misuderstanding... which would/could you use for
version control?
The XML interface.
It still seems to me that a blend
Hi!
By the way -- is it me, or is the current Import/Export interface
broken? I tried to select multiple objects to export, but I can only
get the first one to actually be exported.
It's not just you.. but never thought about whether this might be
a bug ;-)
-- christian
--
COM.lounge
"Chris McDonough" [EMAIL PROTECTED] writes:
Are you thinking that we would build client-side tools to recognize an
XML
representation of a subpart of a site?
Client-side tools, no. I'm thinking that exporting to XML would allow
existing tools to recognize and manipulate a subpart
Steve Spicklemire wrote:
I posted this to the Wiki... but it's not "in-your-face" like email,
so I never know if anyone reads it.
Thanks for sending this to e-mail. (I never read the Wikis -- I mean
to, but never find the time.)
I'm looking
at all this from the perspective of someone who
Hi Fred,
"Fred" == Fred Wilson Horch [EMAIL PROTECTED] writes:
Fred Steve Spicklemire wrote:
I'm looking at all this from the perspective of someone who is
using the current xml/zexp code to manage objects in CVS today
Fred Can you tell me how you do that? Our big problem
Chris McDonough [EMAIL PROTECTED] writes:
I think the only good reasons we have right now for having
filesystem-compatible serialization are to make Zope content editable via
common tools in a way that makes sense to people not used to (or comfortable
with) the object database, and to give
Are you thinking that we would build client-side tools to recognize an
XML
representation of a subpart of a site?
Client-side tools, no. I'm thinking that exporting to XML would allow
existing tools to recognize and manipulate a subpart of a site.
Which ones?
I'm basically agreeing
Wanted to follow up on Steve's points.
He wrote in part:
[...] It seems to me that the current import/export
mechanism is actually pretty close to what we need for serialization.[...]
A) All objects are faithfully encoded and saved on the filesystem
in a text format that any
Hi Folks,
I posted this to the Wiki... but it's not "in-your-face" like email,
so I never know if anyone reads it. Here are a few, possibly random,
but nonetheless concrete, thoughts of mine on the matter. I'm looking
at all this from the perspective of someone who is using the current
xml/zexp
"Chris McDonough" [EMAIL PROTECTED] writes:
I don't think it's reasonable or wise to impose any "master
structure" for filesystem serialization of bodies of
objects. Each instance (or perhaps each class) should
define how best to serialize itself to disk.
Representations between classes
PROTECTED]; "Fred Wilson Horch"
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, March 22, 2001 8:17 PM
Subject: Re: [Zope-dev] FTP interface being worked on?
"Chris McDonough" [EMAIL PROTECTED] writes:
I don't think it's reasonable or wise to impose any "mas
On Mon, 19 Mar 2001, John D. Heintz wrote:
I'm not sure that in the most general case this would solve the problem
either. :-( How do we know when the value (or rather the change in
value) of a property for some Zope object should trigger some method?
This is a definate advantage of
Chris McDonough wrote:
That's one use, which is important to you. Another is to
use Emacs or Dreamweaver on a representation of, for
example, DTML methods on a filesystem, which is important to
other folks.
I think there is really only one issue nobody has been able to sort out:
do we want
I hadn't thought of the issues you raise. Thanks for mentioning them.
"John D. Heintz" wrote in part:
If we
standardize "properties" to an XML file, then optionally dump other
files to expose specific aspects of an instance for serialized editing
it might not be as big a problem as I was
I think there is really only one issue nobody has been able to sort out:
do we want the objects to be actually stored on the filesystem or do we
want to be able to mirror a ZODB? Or do we want both?
My conception of it is that objects won't be served from the filesystem, but
just put in a
Fred Wilson Horch wrote:
I hadn't thought of the issues you raise. Thanks for mentioning them.
These are issues that may very well affect everyone and I'm happy to
share my thoughts.
I guess I would suggest that the serialized form of a Zope instance by
default would be a single XML
Chris McDonough wrote:
I think there is really only one issue nobody has been able to sort out:
do we want the objects to be actually stored on the filesystem or do we
want to be able to mirror a ZODB? Or do we want both?
My conception of it is that objects won't be served from the
How useful/difficult would it be to put the SMB protocol on top of a ZEO
server? As serialized formats are build, would this be useful to anyone?
I'm not sure how hard it would be, although currently ZEO servers need not
know about anything but strings (they don't necessarily need the code
--On Saturday, March 17, 2001 08:46:26 PM -0500 Fred Wilson Horch
[EMAIL PROTECTED] wrote:
I think lossless serialization should be an explicit goal. If a
developer doesn't provide specific object serialization methods, then a
default method (perhaps XML) should be invoked that is
"Dan L. Pierson" wrote in part:
I think lossless serialization should be an explicit goal.
What is lossless vs. non-lossless?
If the filesystem representation dumps evrything required to recreate a
working copy of the catalog after a (perhaps lengthy) computation but
doesn't actually
Chris McDonough wrote:
Fred Horch wrote:
My major question is I don't understand the design
decision to allow lossy representation. [...]
I think lossless serialization should be an explicit
goal. If a developer doesn't provide specific object serialization
methods, then a default
On Sun, 18 Mar 2001, Dan L. Pierson wrote:
representation of Chris' proposal. FSDump has no read capability. At
IPC9, someone
from DC told me that Tres was worried that read capability would be a giant
security
hole. I can't remember if that someone was Tres or not. IMHO, the
On Sun, 18 Mar 2001, Chris McDonough wrote:
"Potentially lossy" also doesn't mean "leaky". It just
means that folks who expose their objects to this sort of
serialization can choose their own format, and if it
represents the object adequately for their own use in both
directions, it's good
Fred Wilson Horch wrote:
Chris McDonough wrote:
Fred Horch wrote:
My major question is I don't understand the design
decision to allow lossy representation. [...]
I think lossless serialization should be an explicit
goal. If a developer doesn't provide specific object serialization
Fred wrote:
I guess I'm voting to rewrite this sentence:
If this API is not implemented by the developer, the
result is
a default serialized representation (perhaps XML
pickle) on a
per-object basis
I think this makes sense.
Maybe the issue is semantics. I think
I hope folks don't mind if I resume the object serialization thread on
the mailing list.
Chris McDonough wrote:
I wonder if yet another interface is really required. If you think
about it, isn't the FTP interface basically a file system serialization
format?
Yes! [...] It's probably
Hi again,
I'm commenting by e-mail because the Wiki interface is too horrible for
me to face on a Saturday night when I should be doing other things. ;-)
Chris McDonough wrote:
I've put the proposal up at
http://dev.zope.org/Wikis/DevSite/Proposals/RepresentingObjectsOnTheFilesyst
em.
* Fred Wilson Horch ([EMAIL PROTECTED]) [010312 10:27]:
Another serialized format that all Zope objects support is the XML
interface, which exposes all the objects' guts. With XML-RPC I
envisioned being able to improve on the FTP interface by adding things
like md5 checksums to determine if
Hi Chris,
Thanks for the pointers to the work others have done. You wrote in
part:
Tres Seaver has done some work on this with his FSDump product
(http://www.zope.org/Members/tseaver/FSDump), although it only goes "one
way" at the moment, and Steve Spicklemire has gone a slightly different
You may also find our documentation process interesting:
http://www.zope.org/DocProjects/intro
Yes, very interesting!
But I'm sorry to see that the Developer's Guide is only in the planning
stages. Here is some info that should go into it (from our Zope notes
at
On Mon, 12 Mar 2001, Fred Wilson Horch wrote:
You may also find our documentation process interesting:
http://www.zope.org/DocProjects/intro
Yes, very interesting!
But I'm sorry to see that the Developer's Guide is only in the planning
stages. Here is some info that should go into
I had not planned to write a Product, but maybe I should reconsider.
For the FTP interface, I had planned to hack on the Zope internals
directly. And for the XML-RPC interface, I had planned to write a
separate client that could leverage the XML-RPC support already built
into Zope.
It's
MAIL PROTECTED]
Sent: Monday, March 12, 2001 11:32 AM
Subject: Re: [Zope-dev] FTP interface being worked on?
Hi Chris,
Thanks for the pointers to the work others have done. You wrote in
part:
Tres Seaver has done some work on this with his FSDump product
(http://www.zope.org/Members/tseav
* Fred Wilson Horch ([EMAIL PROTECTED]) [010312 10:27]:
Another serialized format that all Zope objects support is the XML
interface, which exposes all the objects' guts. With XML-RPC I
envisioned being able to improve on the FTP interface by adding things
like md5 checksums to determine if
Hi folks,
Is anyone working on the FTP support in Zope? For our project, we'd
like to improve the FTP interface to Zope.
I noticed that ZServer/README.txt in Zope 2.3.1b1 states
Properties and FTP: The next step
The next phase of FTP support will allow you to edit properties of
all
. I'd be interested in seeing your proposal too.
The best place for these sorts of things are at http://dev.zope.org (the
"fishbowl")...
Thanks!
- C
- Original Message -
From: "Fred Wilson Horch" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, March 11, 20
Hi Chris,
You wrote in part:
The "export as files" paradigm is something we'd really like to see soon in
Zope. [...] I'd be interested in seeing your proposal too.
Great to hear we're thinking alike. My proposals are available on our
SourceForge site (sorry for the long URL -- I can send
l Message -
From: "Fred Wilson Horch" [EMAIL PROTECTED]
To: "Chris McDonough" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, March 11, 2001 11:30 PM
Subject: Re: [Zope-dev] FTP interface being worked on?
Hi Chris,
You wrote in part:
The "export as files&q
42 matches
Mail list logo
