Paris sprint is ending, here is a quick report
Kamon Ayeva
I made some progress after the prototyping work Kai and I did yesterday.
First, we found that for some reason, using plone.relations to build relationships between "social actors" needs manipulating persistent objects, so we had difficulty to achieve the simple use case of a member adding a friend to his friends list, using plain memberdata.
With the hypothese that the SocialActor has a proxy which is a persistent object (currently I am simply using the MemberFolder, the social actor being a plain Plone user), I can manage to add contacts for a connected member. So we should be able to have an interface where you can see members and add them to your friends list.
I will continue when I get at home, fixing a security bug, and provide a quick interface so people can test, and tomorrow I will commit my changes to the collective.
More details and discussion tomorrow.
Cheers,
Kamon
Christian Scholz / Tao Takashi (SL)
I made some progress after the prototyping work Kai and I did yesterday.
Cool! :-)
First, we found that for some reason, using plone.relations to build relationships between "social actors" needs manipulating persistent objects, so we had difficulty to achieve the simple use case of a member adding a friend to his friends list, using plain memberdata.
Well, I was working on plone.base.profile today and I basically created a layer on top of it which can be used like this:
membermgr = MemberManager(plonesite)
member = membermgr.getMemberById('myname')
member is then a virtual object but could be persistent by making your own member manager
It implements IMember which then be used to adapt whatever to it, like
basicinfo = IBasicMemberInfo(member)
print basicinfo.fullname
I will check this in later. It's on my laptop which run out of battery earlier.
So maybe this can help and the member manager can make persistent members on the fly.
This all might also lead to an replacement of the memberdata tool maybe which is more extensible.
With the hypothese that the SocialActor has a proxy which is a persistent object (currently I am simply using the MemberFolder, the social actor being a plain Plone user), I can manage to add contacts for a connected member. So we should be able to have an interface where you can see members and add them to your friends list.
Cool! :-)
I will continue when I get at home, fixing a security bug, and provide a quick interface so people can test, and tomorrow I will commit my changes to the collective.
More details and discussion tomorrow.
Great news, esp. that we get started on all of this! :-)
-- christian
--
Christian Scholz
Tao Takashi (Second Life name)
taota...@gmail.com
Blog/Podcast: http://mrtopf.de/blog
Planet: http://worldofsl.com
Company: http://comlounge.net
Tech Video Blog: http://comlounge.tv
IRC: MrTopf/Tao_T
Dylan Jay
Hi all,
I tried to join in remotely but I guess sprints are meant to be in one location for a reason. Without that level of direct communication I don’t think its easy to get things done fast.
In the absence of anyone else I started on the invite core code. If there is someone more familiar with z3 utilities can you give me some advice on where to go next with it?
Didn’t see you online yesterday Kamon, which is a pity because it’s odd about needing a persistent object because there used to be code in plone.relations that already worked for ordinary members. Using a proxy.
http://article.gmane.org/gmane.comp.web.zope.plone.cvs/17877
Since members have a unique id (member id) then it should be possible right?
Anyone more familiar with plone relations?
The next steps I think are to create a basic UI for the social graph to inform the framework that kai and Kamon are making so as to focus it on whats needed. And to finish the invite code and then integrate the invite code into the socialgraph ui.
The basic UI for a socialgraph in plone could be that a user to can add other users to one or more of his/her contact lists. A user has 1 or more contact lists, Each contact list has a name which the user label whatever they want, “friend”, “enemy”, “people not to sit next to next plone conference because they smell”. I suspect this might be general enough for a large enough subset of usecases to be useful.
Dylan.
Dylan Jay
Found the code
http://dev.plone.org/plone/browser/plone.app.relations/trunk/plone/app/relations/userrelations.py
http://dev.plone.org/plone/browser/plone.app.relations/trunk/plone/app/relations/userrelations.txt
It’s in the trunk version of plone.app.relations
Kamon Ayeva
Hi!
I made some progress after the prototyping work Kai and I did yesterday.
Cool! :-)First, we found that for some reason, using plone.relations to build relationships between "social actors" needs manipulating persistent objects, so we had difficulty to achieve the simple use case of a member adding a friend to his friends list, using plain memberdata.
Well, I was working on plone.base.profile today and I basically created a layer on top of it which can be used like this:
membermgr = MemberManager(plonesite)
member = membermgr.getMemberById('myname')
member is then a virtual object but could be persistent by making your own member manager
It implements IMember which then be used to adapt whatever to it, like
basicinfo = IBasicMemberInfo(member)
print basicinfo.fullname
That's cool.
I guess membermgr.getMemberById() is authorized for an authenticated, to the contrary of Plone's portal_membership.getMemberById which is not.
I will check this in later. It's on my laptop which run out of battery earlier.
So maybe this can help and the member manager can make persistent members on the fly.
This all might also lead to an replacement of the memberdata tool maybe which is more extensible.
Yes.
It would provide a clean design with separation of concerns to go further with the prototype we've done this week-end.
With the hypothese that the SocialActor has a proxy which is a persistent object (currently I am simply using the MemberFolder, the social actor being a plain Plone user), I can manage to add contacts for a connected member. So we should be able to have an interface where you can see members and add them to your friends list.
Cool! :-)I will continue when I get at home, fixing a security bug, and provide a quick interface so people can test, and tomorrow I will commit my changes to the collective.
More details and discussion tomorrow.
Great news, esp. that we get started on all of this! :-)
Yes, I am really excited by this.
-- Kamon
Kamon Ayeva
Hi all,
I tried to join in remotely but I guess sprints are meant to be in one location for a reason. Without that level of direct communication I don't think its easy to get things done fast.
In the absence of anyone else I started on the invite core code. If there is someone more familiar with z3 utilities can you give me some advice on where to go next with it?
Didn't see you online yesterday Kamon, which is a pity because it's odd about needing a persistent object because there used to be code in plone.relations that already worked for ordinary members. Using a proxy.
http://article.gmane.org/gmane.comp.web.zope.plone.cvs/17877
Ah ok.
Weird, I thought I was online and that you were not.
Since members have a unique id (member id) then it should be possible right?
Anyone more familiar with plone relations?
The next steps I think are to create a basic UI for the social graph to inform the framework that kai and Kamon are making so as to focus it on whats needed. And to finish the invite code and then integrate the invite code into the socialgraph ui.
The basic UI for a socialgraph in plone could be that a user to can add other users to one or more of his/her contact lists. A user has 1 or more contact lists, Each contact list has a name which the user label whatever they want, "friend", "enemy", "people not to sit next to next plone conference because they smell". I suspect this might be general enough for a large enough subset of usecases to be useful.
-- Kamon
Kamon Ayeva
Oh, so that's what Kai and I spent time trying to (re)implement during the sprint.
Anyway I also saw code from Sylvain Viollon (who helped me on plone.relations yesterday), where he has formib widgets for adding relations between objects and he is planning to package and release that in the near future. So it this is needed for our UI work, I could talk to him.
-- Kamon
Christian Scholz
In the meanwhile I also checked in my plonesocial.base.profile of
which I have no idea though if it works or not ;-)
(didn't had the time but wanted to get it out as what I was writing on
the train).
It seems that things are a bit duplicated now from looking at
plonesocial.socialgraph ;-)
I also discussed with Dylan on IRC today a bit and here is a mix of my
thoughts and what we came up with:
- I'd like to rename socialgraph to contacts (e.g.
plonesocial.base.contacts) as I feel that socialgraph might be
better reserved for something which spans more than one site. E.g.
the graph of contacts between many sites.
- I wonder if we should maybe rename SocialActor etc. to simply Member
as I think it's more common. SocialActor
sounds more academic which is of course ok but my fear is that some
people have problems with too much academic
talk ;-)
- Dylan and I discussed that plonesocial.base.profile might be renamed
to .member because a member is the basic thing
and we might attach profiles to it.
- In socialgraph I now see SocialActor and SocialActorProxy. If you
look into my package you might see IMember and an adapter
for the plone site to retrieve an object (a proxy basically)
implementing IMember. This is not persistent and the idea was that it
can act as a point on which you can adapt something. I do this with
IBasicMemberData. I wonder what approach is better. And
what about factoring it out to .profile/.member? My MemberManager
can of course also be changed to provide persistent member
objects. I don't see a real need for a proxy here though.
So that have been my remarks. Feedback is welcome :-)
And although we might have duplicated efforts here maybe we can throw
all this together and see what mix might do the job best.
Eventually we have to change something anyway should we try to write
applications on top of it.
But great work everybody! :-)
Moreover I wonder if we should maybe do some skype conference or so to
discuss things a bit more in realtime.
cheers,
Christian
PS: My Skype Id is "HerrTopf", feel free to add me.
On Apr 28, 3:24 pm, "Kamon Ayeva" <kamon.ay...@gmail.com> wrote:
> On Mon, Apr 28, 2008 at 8:36 AM, Dylan Jay <dja...@gmail.com> wrote:
>
> > Found the code
>
>
> >http://dev.plone.org/plone/browser/plone.app.relations/trunk/plone/ap...
Dylan Jay
> From: plone-socia...@googlegroups.com [mailto:plone-social-
> netwo...@googlegroups.com] On Behalf Of Christian Scholz
> Sent: Tuesday, 29 April 2008 5:52 AM
> To: Plone Social Networking
> Subject: Re: Paris sprint is ending, here is a quick report
>
>
> Hi!
>
> In the meanwhile I also checked in my plonesocial.base.profile of
> which I have no idea though if it works or not ;-)
> (didn't had the time but wanted to get it out as what I was writing on
> the train).
>
> It seems that things are a bit duplicated now from looking at
> plonesocial.socialgraph ;-)
>
> I also discussed with Dylan on IRC today a bit and here is a mix of my
> thoughts and what we came up with:
>
> - I'd like to rename socialgraph to contacts (e.g.
> plonesocial.base.contacts) as I feel that socialgraph might be
> better reserved for something which spans more than one site. E.g.
> the graph of contacts between many sites.
Just realised contacts might also be confusing as we're using it with regard
to contact importing, for instance for importing email addresses from
hotmail etc.
I just noticed in Plaxo its called connections.
Linkedin uses Contacts as a menu item then tabs for connections and imported
contacts. It has "add connections" "remove connections".
Anyone object to that?
Friends or buddies won't work as it doesn't work for all possible
relationships.
> - I wonder if we should maybe rename SocialActor etc. to simply Member
> as I think it's more common. SocialActor
> sounds more academic which is of course ok but my fear is that some
> people have problems with too much academic
> talk ;-)
+1 for that. Plone site users are called members. Lets keep it that to avoid
confusion.
> - Dylan and I discussed that plonesocial.base.profile might be renamed
> to .member because a member is the basic thing
> and we might attach profiles to it.
>
> - In socialgraph I now see SocialActor and SocialActorProxy. If you
> look into my package you might see IMember and an adapter
> for the plone site to retrieve an object (a proxy basically)
> implementing IMember. This is not persistent and the idea was that it
> can act as a point on which you can adapt something. I do this with
> IBasicMemberData. I wonder what approach is better. And
> what about factoring it out to .profile/.member? My MemberManager
> can of course also be changed to provide persistent member
> objects. I don't see a real need for a proxy here though.
>
> So that have been my remarks. Feedback is welcome :-)
>
> And although we might have duplicated efforts here maybe we can throw
> all this together and see what mix might do the job best.
> Eventually we have to change something anyway should we try to write
> applications on top of it.
Lets put it all together in plonesocial.common.member or and then build a
plonesocial.app.connections??? What does .app mean anyway?
>
> But great work everybody! :-)
>
> Moreover I wonder if we should maybe do some skype conference or so to
> discuss things a bit more in realtime.
Lets do it. I'm 'dylan_jay' on skype or 'djjay' on irc.freenode
Kamon Ayeva
+1 for connections.
Friends or buddies won't work as it doesn't work for all possible
relationships.
+1 for that. Plone site users are called members. Lets keep it that to avoid
> - I wonder if we should maybe rename SocialActor etc. to simply Member
> as I think it's more common. SocialActor
> sounds more academic which is of course ok but my fear is that some
> people have problems with too much academic
> talk ;-)
confusion.
Ok, no objection.
Lets put it all together in plonesocial.common.member or and then build a
> - Dylan and I discussed that plonesocial.base.profile might be renamed
> to .member because a member is the basic thing
> and we might attach profiles to it.
>
> - In socialgraph I now see SocialActor and SocialActorProxy. If you
> look into my package you might see IMember and an adapter
> for the plone site to retrieve an object (a proxy basically)
> implementing IMember. This is not persistent and the idea was that it
> can act as a point on which you can adapt something. I do this with
> IBasicMemberData. I wonder what approach is better. And
> what about factoring it out to .profile/.member? My MemberManager
> can of course also be changed to provide persistent member
> objects. I don't see a real need for a proxy here though.
>
> So that have been my remarks. Feedback is welcome :-)
>
> And although we might have duplicated efforts here maybe we can throw
> all this together and see what mix might do the job best.
> Eventually we have to change something anyway should we try to write
> applications on top of it.
plonesocial.app.connections??? What does .app mean anyway?
Ok.
Seems that 'app' is for contrasting a pure library thing ? the thing that depends on Plone basically ?
>
> But great work everybody! :-)
>
> Moreover I wonder if we should maybe do some skype conference or so to
> discuss things a bit more in realtime.
Lets do it. I'm 'dylan_jay' on skype or 'djjay' on irc.freenode
I am heading to the Grokkerdam sprint today.
Tomorrow I will be able to tell you when and how I can continue the discussion with you.
But go ahead if you need to make progress on this. I agree with the things being proposed and we need to move.
-- Kamon
Christian Scholz / Tao Takashi (SL)
+1 for connections then :)
as for .app, my thinking was, that something like .base (or .common, probably does not matter which if the two) is for basic functionality which
maybe has no own UI but just is infrastructure needed.
.app on the contrary might then be something which solves a real user problem with UI and everything.
But that was just a quick idea, maybe it makes no sense. If we use some name like plonesocial.invite.base and .invite.whatever when the whole invite tree gets the app I suppose. So don't worry about it :)
The other idea I had was "bundle" which might be buildouts which create example social networking sites or so. Also not sure that makes sense but it will be a while until we will need this anyway (or when it makes sense).
cheers,
Christian