View this page "ComponentModel"
djay
bunch of other possible use cases. More use cases would be good. For
my needs I'd only need 1-2 of the modules and I'm just getting up
speed on the zope3 stuff so I'm not sure how good a job I'd do. Anyone
feel confident with that?
Also I think if we design it carefully we can minimise the places it
hooks into plone with will make plone3 vs plone2 issues much less of a
problem. I think the major difference is in viewlets, portlets between
them right?
Click on http://groups.google.com/group/plone-social-networking/web/componentmodel
- or copy & paste it into your browser's address bar if that doesn't
work.
kamon
1) Api: invite(username, callonRegistration). Did you mean
invite(useremail, callonRegistration) ?
2) plonesocial.share : Only for the Viewer authorization, we could
allow the 2nd option. Does not seem to me that it would be easy to
imlement though.
3) The profile "privacy" parts seem important to me. You should be
able to hide some part of your memberdata to the others (non-friends,
even friends, etc...)
kamon
Rudá Porto Filgueiras (ruda_porto)
social relation components (plonesocial.relation), they will go in
plonesocial.socialgraph? Relation and Actor will be important modules.
And something like plonesocial.site to hold global properties,
configuration and constraints?
Dylan Jay
> From: plone-socia...@googlegroups.com [mailto:plone-social-
> netwo...@googlegroups.com] On Behalf Of Rudá Porto Filgueiras
> (ruda_porto)
> Sent: Sunday, 9 March 2008 2:57 AM
> To: Plone Social Networking
> Subject: Discussão sobre componentmodel
>
>
> Module to define social actor components (plonesocial.actor) and
Actors are the same as Plone members are they not? So there is no need to
model them seperatly as far as I can see.
> social relation components (plonesocial.relation), they will go in
> plonesocial.socialgraph? Relation and Actor will be important modules.
Relations == socialgraph. The names I picked were the first that came to
mind. Is relations are more accepted name? In the Plone would this would be
easy to comfuse with Plone.relations which is more general (but a good code
base to implement it)
> And something like plonesocial.site to hold global properties,
> configuration and constraints?
What global properties? I'd see each module storing its own properties and
configuration. In that way they can be used independently.
>
Rudá Porto Filgueiras
>
> > -----Original Message-----
> > From: plone-socia...@googlegroups.com [mailto:plone-social-
> > netwo...@googlegroups.com] On Behalf Of Rudá Porto Filgueiras
> > (ruda_porto)
> > Sent: Sunday, 9 March 2008 2:57 AM
> > To: Plone Social Networking
> > Subject: Discussão sobre componentmodel
> >
> >
> > Module to define social actor components (plonesocial.actor) and
>
> Actors are the same as Plone members are they not? So there is no need to
> model them seperatly as far as I can see.
Actors can be users or not. People, company, community, university,
etc, and it can adapt users, so they can have login and roles.
> > social relation components (plonesocial.relation), they will go in
> > plonesocial.socialgraph? Relation and Actor will be important modules.
>
> Relations == socialgraph. The names I picked were the first that came to
> mind. Is relations are more accepted name? In the Plone would this would be
> easy to comfuse with Plone.relations which is more general (but a good code
> base to implement it)
socialrelation, maybe ;-)
> > And something like plonesocial.site to hold global properties,
> > configuration and constraints?
I was talking about "social site" global properties: site is
restricted to join or not, global policies, etc.
> What global properties? I'd see each module storing its own properties and
> configuration. In that way they can be used independently.
yes, I agree, specific module properties should stay in module
--
Rudá Porto Filgueiras
Weimar Consultoria
http://python-blog.blogspot.com
Hospedagem Plone, Zope e Python?
http://www.pytown.com
Dylan Jay
> From: plone-socia...@googlegroups.com [mailto:plone-social-
> netwo...@googlegroups.com] On Behalf Of Rudá Porto Filgueiras
> Sent: Tuesday, 11 March 2008 12:46 AM
> To: plone-socia...@googlegroups.com
> Subject: Re: Discussão sobre componentmodel
>
> On Sun, Mar 9, 2008 at 10:30 PM, Dylan Jay <dja...@gmail.com> wrote:
> >
> > > -----Original Message-----
> > > From: plone-socia...@googlegroups.com [mailto:plone-social-
> > > netwo...@googlegroups.com] On Behalf Of Rudá Porto Filgueiras
> > > (ruda_porto)
> > > Sent: Sunday, 9 March 2008 2:57 AM
> > > To: Plone Social Networking
> > > Subject: Discussão sobre componentmodel
> > >
> > >
> > > Module to define social actor components (plonesocial.actor) and
> >
> > Actors are the same as Plone members are they not? So there is no need
> to
> > model them seperatly as far as I can see.
>
> Actors can be users or not. People, company, community, university,
> etc, and it can adapt users, so they can have login and roles.
So whats a specific example of what you're trying to achieve? Do you want a
user to be able to add a university as a friend? If so what does that mean?
Christian Scholz / Tao Takashi (SL)
> > > -----Original Message-----So whats a specific example of what you're trying to achieve? Do you want a
> > > From: plone-socia...@googlegroups.com [mailto:plone-social-
> > > netwo...@googlegroups.com] On Behalf Of Rudá Porto Filgueiras
> > > (ruda_porto)
> > > Sent: Sunday, 9 March 2008 2:57 AM
> > > To: Plone Social Networking
> > > Subject: Discussão sobre componentmodel
> > >
> > >
> > > Module to define social actor components (plonesocial.actor) and
> >
> > Actors are the same as Plone members are they not? So there is no need
> to
> > model them seperatly as far as I can see.
>
> Actors can be users or not. People, company, community, university,
> etc, and it can adapt users, so they can have login and roles.
user to be able to add a university as a friend? If so what does that mean?
Well, I think we really should hide all that behind an IActor interface (or IMember or whatever it's name is). Then we
can provide an adapter from a membrane or normal user to that interface or from whatever other entity.
Then we also don't need to care about what's behind it. There is a defined interface with the attributes and methods (and the names of them) we need for the system to work. Esp. we would be implementation independant then.
I'd also think that we have several interfaces for portions of a profile. Each component can then choose that interface which has the data it needs and we can provide adapters from any membrane based or normal user to that interface (e.g. with membrane the profile is not defined, a programmer can choose to use emailadr instead of email etc. and an adapter can convert this into the right format then).
-- 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
Rudá Porto Filgueiras
<tao.t...@googlemail.com> wrote:
> Hi!
>
>
>
> >
> > > > > -----Original Message-----
> > > > > From: plone-socia...@googlegroups.com
> [mailto:plone-social-
> > > > > netwo...@googlegroups.com] On Behalf Of Rudá Porto Filgueiras
> > > > > (ruda_porto)
> > > > > Sent: Sunday, 9 March 2008 2:57 AM
> > > > > To: Plone Social Networking
> > > > > Subject: Discussão sobre componentmodel
> > > > >
> > > > >
> > > > > Module to define social actor components (plonesocial.actor) and
> > > >
> > > > Actors are the same as Plone members are they not? So there is no
> need
> > > to
> > > > model them seperatly as far as I can see.
> > >
> > > Actors can be users or not. People, company, community, university,
> > > etc, and it can adapt users, so they can have login and roles.
> >
> > So whats a specific example of what you're trying to achieve? Do you want
> a
> > user to be able to add a university as a friend? If so what does that
> mean?
Not a friend relation, but professor or researcher etc.
It's a generic concept and let specific user case decide which kind of
actors must be valid and which kind of relations exist to connect
them.
Think about a social network of students and professors, each
university is like a community, the students can connect each other
and connect with universities.
> Well, I think we really should hide all that behind an IActor interface (or
> IMember or whatever it's name is). Then we
> can provide an adapter from a membrane or normal user to that interface or
> from whatever other entity.
It's (Interfaces) what will provide flexibility, for actors,
relations, and to all other base domain components/concepts.
> Then we also don't need to care about what's behind it. There is a defined
> interface with the attributes and methods (and the names of them) we need
> for the system to work. Esp. we would be implementation independant then.
:-)
Use cases will help us to find common and specific behavior and to
design Interfaces and components to support the most common and some
specific needs.
I will post some use cases later this week.
> I'd also think that we have several interfaces for portions of a profile.
> Each component can then choose that interface which has the data it needs
> and we can provide adapters from any membrane based or normal user to that
> interface (e.g. with membrane the profile is not defined, a programmer can
> choose to use emailadr instead of email etc. and an adapter can convert this
> into the right format then).
> -- 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
>
>
> >
>
--
Patrick
What I want is ease of use.
About Plone Social Share: I personally liked the Flickr approach (not
sure if they still have it now): you share a piece of content with
others whilst plone immediately creates an account for you. The
content can then be viewed by the person you share it with, by
clicking on a link which automatically logs you in. You can always
change your password later. Username = email address.
The so called "second option" should work well for viral marketing. If
I have a piece of content and I want people to forward that link, then
that's great. Perhaps there is even a way to automatically create the
accounts for them as well, or when they click on the link have a pop
up showing email, password registration. (Thats all we ask at present
as well). Something along those lines to support the "buzz" effect.
And it has to be done easy. I do not want to deal with a lot of clicks
to make it happen. (I am speaking from a user perspective here).
Second: Inviting social graph. I think we *most definitely* should
have a way to log into your hotmail/yahoo/linkedin etc accounts and
import your list of users. There is *no way* I (personally, as a user)
would be willing to do this manually, especially when this process is
used in so many networks these days already and people are used to
doing this already. I do not see what the point is of inviting people
that are not part of my platform yet, if I cannot import their emails
from somewhere.
Christian Scholz / Tao Takashi (SL)
Sorry for my quietness aswell, laptop broke, busyness and so on.. ;-)
And now I am in Sorrento and probably busy with plone.commenting ;)
Hi Sorry I was travelling hence my late participation.
What I want is ease of use.
About Plone Social Share: I personally liked the Flickr approach (not
sure if they still have it now): you share a piece of content with
others whilst plone immediately creates an account for you. The
content can then be viewed by the person you share it with, by
clicking on a link which automatically logs you in. You can always
change your password later. Username = email address.
Sounds good as one possible application.
The so called "second option" should work well for viral marketing. If
I have a piece of content and I want people to forward that link, then
that's great. Perhaps there is even a way to automatically create the
accounts for them as well, or when they click on the link have a pop
up showing email, password registration. (Thats all we ask at present
as well). Something along those lines to support the "buzz" effect.
And it has to be done easy. I do not want to deal with a lot of clicks
to make it happen. (I am speaking from a user perspective here).
I don't get why this piece of content should not be public then. Viral sort of implies to me that it's public.
You can of course always create an account then.
I agree that user signup should be as easy as possible (but of course that also should be up to the application
what they decide to use and if they want to put a 4 page form in front of a new user before they can do anything).
So what it should support would be that you can use an application maybe without to be logged in at all and if you want
to persist things you might want to create an account by basically choosing a username and password or giving your openid. You might then optionally add more data later.
This if course is also mostly app specific but we should make sure we don't require any additionally data where we can avoid it.
Second: Inviting social graph. I think we *most definitely* should
have a way to log into your hotmail/yahoo/linkedin etc accounts and
import your list of users. There is *no way* I (personally, as a user)
would be willing to do this manually, especially when this process is
used in so many networks these days already and people are used to
doing this already. I do not see what the point is of inviting people
that are not part of my platform yet, if I cannot import their emails
from somewhere.
Well, gladly more and more people seem to provide APIs to do that instead of giving out your passwords.
Google: http://mrtopf.de/blog/secondlife/google-releases-contacts-data-api/
Microsoft: http://mrtopf.de/blog/en/data-portability-news-microsoft-scoble-facebook-and-labs/
Facebook also has some API for getting contacts
Using any XFN providing network is also useful without needing a password (Twitter, Pownce, ...)
The problem is though that all those APIs seem to use different formats for their contacts. So this sounds like extra work but I hope we can standardize on something at some point when the DataPortability Project gets more active and focused.
cheers,
Christian
Dylan Jay
> From: plone-socia...@googlegroups.com [mailto:plone-social-
> netwo...@googlegroups.com] On Behalf Of Patrick
> Sent: Thursday, 27 March 2008 12:31 AM
> To: Plone Social Networking
>
>
> Hi Sorry I was travelling hence my late participation.
>
> What I want is ease of use.
>
> About Plone Social Share: I personally liked the Flickr approach (not
> sure if they still have it now): you share a piece of content with
> others whilst plone immediately creates an account for you. The
> content can then be viewed by the person you share it with, by
> clicking on a link which automatically logs you in. You can always
> change your password later. Username = email address.
I like the autologin feature but not sure about making the login the email
address that someone else knows me by. For instance if I use a personalised
domain name with a catchall. This allows me to register with facebook as
face...@mydomain.com. This helps with spam control as well as helping
remember what username I choose for X site.
So I'd like to also support either being able to change usernames easily
later. I'd also like to support being able to register many different email
addresses like facebook allows me too. That way when users add me via my my
hotmail address they will find me in the system even if system messages are
being sent to another address.
We just need to work out an architecture that handles all of that.
My initial thoughts would be tool that is responsible for storing and
associating all email addresses and other online identities (like hotmail
and linkedin etc) for a single user. Ie something separate from the normal
Plone member profile, but able to be edited from the personal preferences
panel. Users inside this tool can either be associated with real Plone
member accounts or be as yet unregistered. This tool handles the emailing of
the special url the user can auto login/register with, an event triggered by
someone wanting to share something for instance. I think the real user
account should be created at the point the user clicks on that link in order
to not have plome member pollution. Then after that, just need a step for
the user to pick a username and password.... and yes it would be great if
that wasn't a required step, and you could set your own username and
password at anytime.
Just not sure if changing a Plone username halfway throough is going to be
very messy. I think PAS allows for a separation of userid and login but I'm
not sure Plone supports that. If it did then userid could just be a unique
number and login could change anytime without hassle.
> The so called "second option" should work well for viral marketing. If
> I have a piece of content and I want people to forward that link, then
> that's great. Perhaps there is even a way to automatically create the
> accounts for them as well, or when they click on the link have a pop
> up showing email, password registration. (Thats all we ask at present
> as well). Something along those lines to support the "buzz" effect.
> And it has to be done easy. I do not want to deal with a lot of clicks
> to make it happen. (I am speaking from a user perspective here).
>
> Second: Inviting social graph. I think we *most definitely* should
> have a way to log into your hotmail/yahoo/linkedin etc accounts and
> import your list of users. There is *no way* I (personally, as a user)
> would be willing to do this manually, especially when this process is
> used in so many networks these days already and people are used to
> doing this already. I do not see what the point is of inviting people
> that are not part of my platform yet, if I cannot import their emails
> from somewhere.
So it seems so far the invite stuff seems a great place to start. As in it's
a base of functionality which is the most reusable for the most amount of
people.
Now we just have to work out how to make it happen.
Dylan Jay
> -----Original Message-----
> From: plone-socia...@googlegroups.com [mailto:plone-social-
> netwo...@googlegroups.com] On Behalf Of Christian Scholz / Tao Takashi
> (SL)
> Sent: Thursday, 27 March 2008 10:57 AM
> To: plone-socia...@googlegroups.com
Agreed. We need to build it in a way that allows the least restrictions on
the regitration process and then make it easy for integrators to add those
restrictions in (ie control panel options maybe, like "make user pick
username at registration time")
I was thinking we could have our own registry for plugins for contact
sources. So anyone can write a plugin to add support for facebook or any
other new source of contacts.
Patrick
perhaps there is a way to create this whole structure while using Zope
3 technologies but still applicable to zope 2, or five or whatever. It
would also have to work, not only with Plone 3 which still seems to
have a lot of issues when dealing with anything other than the most
basic features, but also with plone 2.5. I like the idea of converging
technologies, where it's all going to be (kinda) the same in 2 years
from now. I think it would help in disseminating the product quicker
if people do not have to re-code everything into Plone 3 (especially
with the issues there still exist). I know it works like that for us
anyway !
Patrick
and Dylan generalized the situation very well. Totally agree.
About how to start: we're facing the dilemma that we do not want to
move to Plone 3.0 anytime soon, since we heard too many stories of
problems, that a site like ours cannot have. Zope 3 would be great. So
this means how to merge Plone 2.5 and Zope 3, Five, Zope2 etc. Second
question is: how much more work is doing this in a generalized way as
opposed to a specific app. Third: what technology to use: Python eggs,
or inside Plone. How useful is all that to others. Any comments would
be much appreciated. We're under considerable time pressure, but we
need something like this ourselves anyway, and if it all fits together
we're more than happy to contribute or (co-)build it.
Christian Scholz / Tao Takashi (SL)
I think something good to have now would be some use case description of it because for me it's still not clear how you think should look like. So best would be first to define roles like
User: A user of the system
Contact: A contact of that user
Then for a use case we need some goal
Goal: User wants to invite a contact to look at his photo (or asset to be more general)
And then start to write some use case scenario a la
1. The User logs in
2. The User uploads a photo
3. The User invites Contact by entering the email address of Contact
4. The System creates an account for the contact. The email address is used as account name, a password is generated.
5. The System sends an email to the contact giving out a link where he can login
(not sure this is right from what you envision). This actually are several use cases in one (login, upload and invitation) but I want to keep it brief here.
Then the next use case would be how the contact reacts.
1. The Contact clicks the link
2. The system shows the login screen
3. The contact enters login and password and submits the form
4. The system logs the user in
5. The system redirects the user to the asset
Now of course many things can go wrong, like the password might be wrong. You write this down as an exception to the normal flow (the normal flow is the main success scenario, nothing goes wrong):
4a. The password given is wrong
4a1. The system tells the user that the password is wrong
4a2. go on to 2
If you have another exception you can use 4b, 4c etc. (if it's in the same step).
So I would propose to write it more down like this, one use case per page. That way we might be all on the same page what we mean. We maybe don't need the exceptions for now but they might be added later. To me this format makes usually more sense because it's more formal and concrete than prose.
The syntax is usually "WHO does WHAT". WHO is then out of the predefined roles.
So it seems so far the invite stuff seems a great place to start. As in it's
a base of functionality which is the most reusable for the most amount of
people.
Now we just have to work out how to make it happen.
:-)
Well, for me it's not that important. I mostly want to have a playground for testing microformats auch as XFN and work on making DataPortability further possible with Plone. My focus would be some sort of social graph modelling. I will try to write down some use cases for this later. It probably will be the basic stuff like
User registers with the system
User fills in his profile information
User adds another user as a contact
Probably that's it already for the basics. This structure can then also be used for an invitation system to create contact relationships automatically or via workflow.
I also started to code an xfn portlet (some blogroll like thing) which I maybe will continue soon and put in the collective. It's sort of standalone though but I thought it might already use the plonesocial namespace as it's somewhat related to the ideas here.
-- Christian
Christian Scholz / Tao Takashi (SL)
The normal approach which is used in Plone is actually to use Eggs. We also usually split between a zope3 package and a more Plone related package. We can do the same with plonesocial where it makes sense to do so. My idea would also be to use zope3 concepts where possible thus modelling everything with interfaces, adapters and utilities. So this way at least parts should also be reusable in Plone3. When it comes to e.g. portlets etc. then of course this will be only Plone3 but could be redone using old-style portlets in Plone 2.5. Not sure what else might be affected, I guess we will find out on the way.
(using invitation via various sources, gmail, ms etc. can actually be a pure python lib)
-- Christian
Dylan Jay
I'm not sure what your reservations are about plone3. I've skipped Plone 2.5
striaght to plone3. The complaints I've heard about plone3 aren't quality
problems, rather the high learning curve of using the zope3 technology +
viewlets + portlet manager. Once you learn that, it seems to all work well.
I have 3 sites on it currently and am switching over my company site to it
tomorrow (migration from 2.0.5 without too much trouble).
Having said all this, I think the aim would be to use zope3 technologies as
much as possible. That means usable in plone2.5 and plone3 and perhaps
zope3. There will however have to be hooks into the Plone UI which might
have to be Plone version specific. I think it would be goal to minimise the
hooks into Plone to make it easy to port. We won't know until we try.
Dylan.
> -----Original Message-----
> From: plone-socia...@googlegroups.com [mailto:plone-social-
> netwo...@googlegroups.com] On Behalf Of Patrick
> Sent: Thursday, 27 March 2008 9:07 PM
> To: Plone Social Networking
djay
down into tasks
Christian Scholz / Tao Takashi (SL)
I've update the compenent model. Just need to work out how to break it
down into tasks
looks cool :-)
What about making it plonesocial.invite.base instead? I think this makes the namespace clearer.
I was also wondering if we should have some base namespace in general for packages which just
provide some infrastructure, like various sorts of profile definitions, such as
plonesocial.base.profile
plonesocial.base.contacts
etc.
They might simply define some interfaces and maybe adapters for a plain Plone site. Specialized ones for your own type of network can then be added at will.
Maybe we also can have some app namespace for finished applications, maybe plonesocial.app.invite can be one which simply requires all the other invite packages and makes them an application by maybe providing some UI.
Then we could also have plonesocial.bundles.<something> which are maybe examples of out-of-the-box social network sites. This is a bit farer in the future though ;-)
I will try to clean up my profile stuff and might check it in as plonesocial.base.profile. This might then be used by the invite stuff.
-- Christian
Click on http://groups.google.com/group/plone-social-networking/web/componentmodel
- or copy & paste it into your browser's address bar if that doesn't
work.
Kamon Ayeva
Hi!On Thu, Apr 24, 2008 at 6:35 PM, djay <dy...@pretaweb.com> wrote:
I've update the compenent model. Just need to work out how to break it
down into tasks
looks cool :-)
Yes.
What about making it plonesocial.invite.base instead? I think this makes the namespace clearer.
I was also wondering if we should have some base namespace in general for packages which just
provide some infrastructure, like various sorts of profile definitions, such as
plonesocial.base.profile
plonesocial.base.contacts
etc.
They might simply define some interfaces and maybe adapters for a plain Plone site. Specialized ones for your own type of network can then be added at will.
I think it's a good idea.
Maybe we also can have some app namespace for finished applications, maybe plonesocial.app.invite can be one which simply requires all the other invite packages and makes them an application by maybe providing some UI.
Then we could also have plonesocial.bundles.<something> which are maybe examples of out-of-the-box social network sites. This is a bit farer in the future though ;-)
I will try to clean up my profile stuff and might check it in as plonesocial.base.profile. This might then be used by the invite stuff.
Ok, super.
-- Kamon
Kamon Ayeva
I've met Kai at the sprint where I finally arrived, and we decided to start tomorrow morning working from what you guys have already put there.
Cheers,
Kamon
There is nothing much there but I checked in a package. It has some old code from PloneInvite
https://svn.plone.org/svn/collective/plonesocial.invite.base/trunk
see what someone else can do.
Dylan Jay
Founder PretaWeb.com, Founder IntroVino.com
Skype:dylan_jay M:+61421477460
From: Kamon Ayeva [mailto:kamon...@gmail.com]
Sent: Friday, 25 April 2008 10:20 PM
To: Dylan Jay
Subject: Re: View this page "ComponentModel"
I will be at the sprint later at the end of the day, in about 3 hours (between 5 and 6 pm CET).
I will check on irc.
-- KamonOn Fri, Apr 25, 2008 at 2:07 PM, Dylan Jay <dj...@pretaweb.com> wrote:
You at the sprint?
I've just got back home.
I'm djjay on irc (or perhaps djja1)
Dylan Jay
Founder PretaWeb.com, Founder IntroVino.com
Skype:dylan_jay M:+61421477460