Re: [Zope3-dev] future of fssync (was: RE: [SpringCleaning07])
Sorry for replying so late. I have just checked in some bug fixes for fssync (r72206). This was indeed not much work. Jim Fulton [EMAIL PROTECTED] wrote: I don't think a whole lot is needed to make fssync a reality: 1. Cure any bitrot that has set in. It would also ne nice to replace existing tests with modern doctests. 2. Provide a Python API. fssync originally had a Python API, but this was replaced with a web-based API. I think there should be both a Python API that wasn't encumbered in any way by security, and a protected web-based API. The Python API should really be Zope and even ZODB independent. I don't think this would be a lot of work. The original one wasn't and would be useful in many cases. 3. I think there should be a secure web-based interface. This will require: - Adding security checks that the user is allowed to access serialization and de-serialization adapters, - Adding security declarations for these adapters, I don't think any of these would require a great deal of work. I can try to deal with these tasks, but I fear that there is a little bit more to do. While playing with real data, I noticed - problems to serialize large sites (I run into a stack overflow and have still to figure out why this happened), - problems with unicode filenames. As a first step I would like to clean up the existing code. Concerning this I have questions/suggestions: - Can the fssync:adapter zcml directive be replaced by ordinary trusted adapters? - Can zope.app.fssync.fspickle be replaced by zope.xmlpickle? (It seems that fspickle preserves location ids but it does not seem to preserve the order of dict items) - What's the purpose of zope.app.fssync.fsbundle? Are there still usecases for this code or can it be removed? - What's the purpose of zope.app.fssync.fsregistry? Can this be replaced by utility registrations? All in all the fssync code seem to be in an old-fashioned but usable shape and it's a pity that it has not been maintained. Perhaps the maintenance can be made easier if we can change the code without deprecation warnings. Nobody seems to have used fssync in the last two years. Regards, Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] future of fssync (was: RE: [SpringCleaning07])
2007/1/24, Uwe Oestermeier [EMAIL PROTECTED]: Perhaps the maintenance can be made easier if we can change the code without deprecation warnings. Nobody seems to have used fssync in the last two years. I think you can take that granted. fssync has been pretty useless so far. -- Best regards, Miklós Prisznyák Principal Consultant, owner http://www.jegenye.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] future of fssync (was: RE: [SpringCleaning07])
On Jan 24, 2007, at 7:18 AM, Uwe Oestermeier wrote: Sorry for replying so late. I have just checked in some bug fixes for fssync (r72206). No apologies needed. Thanks for picking this up! This was indeed not much work. Jim Fulton [EMAIL PROTECTED] wrote: I don't think a whole lot is needed to make fssync a reality: 1. Cure any bitrot that has set in. It would also ne nice to replace existing tests with modern doctests. 2. Provide a Python API. fssync originally had a Python API, but this was replaced with a web-based API. I think there should be both a Python API that wasn't encumbered in any way by security, and a protected web-based API. The Python API should really be Zope and even ZODB independent. I don't think this would be a lot of work. The original one wasn't and would be useful in many cases. 3. I think there should be a secure web-based interface. This will require: - Adding security checks that the user is allowed to access serialization and de-serialization adapters, - Adding security declarations for these adapters, I don't think any of these would require a great deal of work. I can try to deal with these tasks, but I fear that there is a little bit more to do. While playing with real data, I noticed - problems to serialize large sites (I run into a stack overflow and have still to figure out why this happened), Hm, interesting. I'll be curious to hear how this turns out. - problems with unicode filenames. Ah, interesting. As a first step I would like to clean up the existing code. Concerning this I have questions/suggestions: - Can the fssync:adapter zcml directive be replaced by ordinary trusted adapters? Maybe, but I like your idea of using utilities below. My original thinking was along these lines: fssync should strive to serialize all object data. (Note that it isn't always obvious what data is intrinsic to an object.) I felt therefore, that inheriting synchronization adapters would be bad. If someone created a subclass and forgot to create an adapter, then their data would be serialized incompletely. I like the idea of using named utilities, using dotted class names as utility ids. See below. An alternative might be to see if some ideas from Ape could be used to catch when an object serialization is incomplete. I think that this would be a lot of work and not something to pursue in the short term. I have, on multiple occasions wanted class-based adapters without inheritance. The security-checker registry is another use case for this. At some point, I'd like to extend the component architecture in this direction. - Can zope.app.fssync.fspickle be replaced by zope.xmlpickle? (It seems that fspickle preserves location ids but it does not seem to preserve the order of dict items) I'm a bit rusty on this. I would think that these can be combined. It should, I think, be possible to generate location-aware pickles and then use zmlpickle to represent these as XML. The trick, I think, would be use the pickle persistent-reference mechanism to refer to other objects by location, when necessary. I say this without looking at the code. :) If you need me to dig deeper, I'll try to find time to do so. - What's the purpose of zope.app.fssync.fsbundle? Are there still usecases for this code or can it be removed? Yes - What's the purpose of zope.app.fssync.fsregistry? Can this be replaced by utility registrations? I believe that this is the class-based adapter registry discussed above. Using utilities is an intriguing idea. Would you use the dotted class name as the utility id? I assume that the utilities would actually be adapter factories. All in all the fssync code seem to be in an old-fashioned but usable shape and it's a pity that it has not been maintained. Yes. It's a pity that there isn't more time to work on useful projects like this. This is also very early code. It goes back to 2002. We've learned a lot since then. Perhaps the maintenance can be made easier if we can change the code without deprecation warnings. Nobody seems to have used fssync in the last two years. +1 Thanks again for looking at this. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] future of fssync (was: RE: [SpringCleaning07])
Jim Fulton [EMAIL PROTECTED] on Mittwoch, 24. Januar 2007 at 16:48 Uhr +0100 wrote: Maybe, but I like your idea of using utilities below. My original thinking was along these lines: fssync should strive to serialize all object data. (Note that it isn't always obvious what data is intrinsic to an object.) I felt therefore, that inheriting synchronization adapters would be bad. If someone created a subclass and forgot to create an adapter, then their data would be serialized incompletely. I like the idea of using named utilities, using dotted class names as utility ids. See below. Ok, I will give named utilities a try. - Can zope.app.fssync.fspickle be replaced by zope.xmlpickle? (It seems that fspickle preserves location ids but it does not seem to preserve the order of dict items) I'm a bit rusty on this. I would think that these can be combined. It should, I think, be possible to generate location-aware pickles and then use zmlpickle to represent these as XML. The trick, I think, would be use the pickle persistent-reference mechanism to refer to other objects by location, when necessary. I say this without looking at the code. :) If you need me to dig deeper, I'll try to find time to do so. I found such a combination in zope.fssync.server.entryadapter. There a location-aware pickle was created by fspickle.dumps and converted via xmlpickle.toxml. This version generated xmlpickles with changing dict representations which in turn led to false alarms that objects had been modified. I will try to combine the xmlpickle._PicklerThatSortsDictItems with the fspickle.ParentPersistentIdGenerator and see whether this solves the problem. If this doesn't work, I will ask you for further assistance. Uwe Dr. Uwe Oestermeier Institut für Wissensmedien Knowledge Media Research Center Konrad-Adenauer-Str. 40 D-72072 Tuebingen Germany [EMAIL PROTECTED] Tel. +49 7071 979-208 Fax +49 7071 979-100 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] calling interface returns object, calling queryAdapter returns None?
Hot on the heels of my multi-adapter problem: http://mail.zope.org/pipermail/zope3-dev/2007-January/021600.html ...which I'm still waiting for guidance on, I now find that queryAdapter and calling an interface behave unexpectedly differently in the case where an object directly implements an interface: from zope.interface import Interface,implements class ITest(Interface): pass ... class Test: ... implements(ITest) ... t = Test() ITest(t) __main__.Test instance at 0x01C6E300 from zope.component import queryAdapter queryAdapter(t,ITest) How come calling the interface returns t but queryAdapter returns None? Should I log this and my previous multi-adapter example as bugs in the collector? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
Chris Withers wrote: Hot on the heels of my multi-adapter problem: http://mail.zope.org/pipermail/zope3-dev/2007-January/021600.html ...which I'm still waiting for guidance on, I now find that queryAdapter and calling an interface behave unexpectedly differently in the case where an object directly implements an interface: from zope.interface import Interface,implements class ITest(Interface): pass ... class Test: ... implements(ITest) ... t = Test() ITest(t) __main__.Test instance at 0x01C6E300 from zope.component import queryAdapter queryAdapter(t,ITest) How come calling the interface returns t but queryAdapter returns None? Should I log this and my previous multi-adapter example as bugs in the collector? cheers, Chris From the Interface.__call__ docstring: If an object already implements the interface, then it will be returned queryAdapter is looking in the adapter registry. You have not registered any adapters. So this looks like the expected behaviour to me. Laurence ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
Laurence Rowe wrote: From the Interface.__call__ docstring: If an object already implements the interface, then it will be returned queryAdapter is looking in the adapter registry. You have not registered any adapters. So this looks like the expected behaviour to me. Documented maybe, expected no. queryAdapter, for me, is starting with the supplied object, get me something that implements the supplied interface and return None if no such object can be obtained. If there's another function which does this, fine, if not, then I maintain the current behaviour is not correct... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
On Jan 24, 2007, at 5:37 PM, Chris Withers wrote: Laurence Rowe wrote: From the Interface.__call__ docstring: If an object already implements the interface, then it will be returned queryAdapter is looking in the adapter registry. You have not registered any adapters. So this looks like the expected behaviour to me. Documented maybe, expected no. queryAdapter, for me, is starting with the supplied object, get me something that implements the supplied interface and return None if no such object can be obtained. If there's another function which does this, fine, if not, then I maintain the current behaviour is not correct... Chris, documented behavior is not incorrect just because you expect otherwise. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
On 1/24/07, Chris Withers [EMAIL PROTECTED] wrote: queryAdapter, for me, is starting with the supplied object, get me something that implements the supplied interface and return None if no such object can be obtained. o = IFoo(ob, None) if os is not None: ... If there's another function which does this, fine, if not, then I maintain the current behaviour is not correct... Er, wrong. Like Jim said, if it's documented... -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Every sin is the result of a collaboration. --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
Jim Fulton wrote: If there's another function which does this, fine, if not, then I maintain the current behaviour is not correct... Chris, documented behavior is not incorrect just because you expect otherwise. Indeed, sorry, that's not what I meant, although I can see it came across like that. Apologies... Les try this again: what's the canonical way to find out if an object either implements a given interface or can be adapted to it? cheers, Chris PS: still looking for confirmation as to whether what I demonstrate in http://mail.zope.org/pipermail/zope3-dev/2007-January/021600.html is a bug or if I'm missing something? -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
Fred Drake wrote: On 1/24/07, Chris Withers [EMAIL PROTECTED] wrote: queryAdapter, for me, is starting with the supplied object, get me something that implements the supplied interface and return None if no such object can be obtained. o = IFoo(ob, None) if os is not None: Ah, now that's what I was looking for, thanks :-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] View permissions
On Mon, Jan 22, 2007 at 05:46:48PM -0500, Jim Fulton wrote:
I might even hack the TextWidget so I could just do:
adapter
factory=.TextWidget
permission=zope.Public
/
+1
I'd be happy to deprecate the view directive.
+1
Caveats: won't it seem strange to newcomers? Maybe there is a place for
some sort of a view directive that is basically an alias for
adapter, and maybe allows you to register a menu item as well?
Also, I'd like a way to specify the adapter name in the adapter class.
Something like
from zope.interface import implements
from zope.component import adapts, named
class MyNamedAdapter(object):
adapts(IFoo)
implements(IBar)
named('myname')
def __init__(self, context):
self.context
Also I'd like to have a zope.component.Adapter class that defines
def __init__(self, context):
self.context
and does nothing else. It seems to me that 95% of all adapters have an
__init__ like this. It is tiring to keep repeating it.
Also, I want a pony. Ok, not really.
Marius Gedminas
--
I may not understand what I'm installing, but that's not my job. I
just need to click Next, Next, Finish here so I can walk to the next
system and repeat the process
-- Anonymous NT Admin
signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: calling interface returns object, calling queryAdapter returns None?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Withers wrote:
Fred Drake wrote:
On 1/24/07, Chris Withers [EMAIL PROTECTED] wrote:
queryAdapter, for me, is starting with the supplied object, get me
something that implements the supplied interface and return None if no
such object can be obtained.
o = IFoo(ob, None)
if os is not None:
Ah, now that's what I was looking for, thanks :-)
Note that for regularity, I assert that the calling the IFoo interface
should allow the follwing use cases, based on the asserition that
utilities are zero-order adapters, just as views are binary order
adapters.
First the setup::
from zope.interface import Interface, Attribute
from zope.interface import implements, directlyProvides
from zope.component import provideUtility, provideAdapter, adapts
class IFoo(Interface):
... name = Attribute(u'Name')
class FooUtil:
... implements(IFoo)
... def __init__(self, name):
... self.name = name
fooUtil = FooUtil('default')
provideUtility(fooUtil)
fooUtilNamed = FooUtil('named')
provideUtility(fooUtilNamed, name='named')
class FooAdapter:
... implements(IFoo)
... adapts(None)
... name = 'default'
... def __init__(self, context):
... self.context = context
class FooAdapterNamed(FooAdapter):
... name = 'named'
provideAdapter(FooAdapter)
provideAdapter(FooAdapterNamed, name='named')
Now the usage. Things which *don't* work today are marked '(SF)'.
Interfaces called with *no* context argument return
utilities, not adapters (SF)::
u_default = IFoo() # return the default utility
u_default.__class__.__name__, u_default.name
('FooUtil', 'default')
Named utilities can also be looked up (SF)::
u_named = IFoo(name='named')
u_named.__class__.__name__, u_named.name
('FooUtil', 'named')
Default adapter lookup works as expected::
context = object()
a_default = IFoo(context)
a_default.__class__.__name__, a_default.name
('FooAdapter', 'default')
But we can also do named adapter lookup (SF)::
a_named = IFoo(context, name='named')
a_named.__class__.__name__, a_named.name
('FooAdapterNamed', 'named')
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFuAt/+gerLs4ltQ4RAmTSAJ0SYhaKb3fPrpeIm1odC02LrbjZuQCfXK/0
NMERLbcjZsBK77OeCWUACYQ=
=wI8F
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
