[pLog-svn] r6088 - plog/branches/lifetype-1.2/class/security
Mark Wu
markplace at gmail.com
Mon Jan 7 09:36:23 EST 2008
Hi Andy:
After read all the replies, I still have no idea about what is the XML file
for? As Oscar said, can you provide an example here and show us how to use
this XML file. I think it is easier for us to undestand this idea with an
example.
Mark
> -----Original Message-----
> From: plog-svn-bounces at devel.lifetype.net
> [mailto:plog-svn-bounces at devel.lifetype.net] On Behalf Of Andy
> Sent: Monday, January 07, 2008 10:00 PM
> To: LifeType Developer List
> Subject: Re: [pLog-svn] r6088 -
> plog/branches/lifetype-1.2/class/security
>
>
>
> On Mon, 7 Jan 2008, Oscar Renalias wrote:
>
> > What does these XML files actually contain? Do you have an example?
> >
> > We'd be happy to provide these two users in addition to the
> > documentation that we generate from the code, but usually
> the problem
> > is maintaining it. Would you have the time to do that? Or
> is there any
> > way that this process can be automated?
>
> As of now, I am taking a long route and entering all API
> data. I am doing this for the primary functions, so I know
> exactly what I am doing when I need access to these resources.
>
> However, I could easily parse all the API resources in your
> /class & class/action with a script. Along with: monitor CVS
> changes on a per submission basis for automatically including
> any changes or additions to the API methods and then check
> them for accuracy.
>
> All data fields contain all member classes, functions, object
> data types, and a personalized and extended description of
> each, along with a couple real world examples for a specific
> data provider.
>
> I am in need of a transformer for PHP and C# data types
> (seperate from the XML schematic and data that I would like
> to submit to LT). This could be easily done with a PHP
> application, but like I said, it has been a while, and I need
> to catch up and get back into the programming mind state.
>
> My development platform is in VS 2005 (got a free licenses
> from a conference, the door attendee loved the firefox
> default linux font, I just kept my mount shut, and walked
> away), with C# using mono's .NET library references. I want
> this to be as portable as possible.
>
> Back to the API data entry, what other type of information
> would you like to see that is not all ready published? URL
> resources for code examples, version control while
> concatenating changes, for reference to releases?
>
> What does everyone think? What would someone developing any
> type of personalized LT installation want to know, or have
> reference to?
>
> Andy
>
> >
> > On Jan 4, 2008 11:24 PM, Andy <myside at myside.mine.nu> wrote:
> >>
> >>
> >>
> >> On Thu, 3 Jan 2008, Oscar Renalias wrote:
> >>
> >>> Excellent feedback and nice discussion so far. We appreciate all
> >>> feedback and support :-)
> >>>
> >>> I would agree that we usually end up making too many
> releases of the
> >>> same stable branch (we reached .6 in the 1.1 branch and
> we're about
> >>> to reach the same milestone-release in the 1.2 one...)
> but sometimes
> >>> it takes a while to get software right so I see that maintenance
> >>> releases are necessary. If you think about it, Jon just
> tracked down
> >>> and fixed a bug that had been haunting some of us since probably
> >>> even 1.1, and I think that is good that we share these
> corrections
> >>> with everyone as often as it takes.
> >>>
> >>> We could consider making regular releases at pre-defined
> intervals,
> >>> at let's say every 2-3 months for maintenance releases and every
> >>> 18-24 months for major ones but considering that LT is just a
> >>> "hobby" for which sometimes we don't have enough time, it
> would be
> >>> difficult to stick to those. Instead, we work on it when
> we can and
> >>> make the releases whenever we think they're ready.
> >>>
> >>> But I will agree with you that sometimes we haven't been
> very strict
> >>> and we have modified core API methods and classes to fix issues
> >>> during maintenance releases, which seems to be one of
> your concerns.
> >>> I assume that if we ensured that the API is 'frozen' during the
> >>> whole duration of the branch that would satisfy cases
> like yours (or
> >>> communicated the changes clearly enough providing sound reasoning
> >>> for them)? If so, we can consider being more strict and
> rigorous from now on.
> >>>
> >>> Now about providing support for older stable releases when a new
> >>> main version has been released, I agree that we were a
> bit too harsh
> >>> with the 1.1->1.2 transition. For the next major release
> (2.0), we
> >>> should maybe think of supporting 1.2 until 2.0.3 is out
> or so, as .3
> >>> is usually the time when most of the major issues with the new
> >>> branch have been sorted out. But supporting it much further than
> >>> that is quite difficult, as our resources are pretty limited and
> >>> time used to support a previous release is time not used
> in working
> >>> on the newest one unless we adopt a model similar to the Linux
> >>> kernel, where there's one person specifically allocated to
> >>> supporting 2.4 while 2.6 is being developed. We would
> only need one
> >>> additional developer to step forward and take that role... Anyone
> >>> interested? :-)
> >>>
> >>> Hopefully we adressed your concerns, but please feel free to
> >>> continue sharing your feedback with us.
> >>>
> >>> Oscar
> >>
> >> That is a wonderfull plan. I am honered that your team has
> >> considered my concerns, agree with some of the recomendations, and
> >> are considering a new plan for release cycles.
> >>
> >> I just created an XML schematic for your API and am now
> entering data
> >> such as inheritances, public and private functions and their
> >> attributes, among other references such as the description
> and member details.
> >>
> >> I figure parsing your API web portal would take the same
> amount of work.
> >>
> >> If I could provide support to this project, making the XML
> schematic
> >> and data available to the public, I would consider it to be an
> >> honerable participation and resource for the Lifetype
> development process.
> >>
> >> Is this something that might be of interest to the project team
> >> members, and would you accept my work into the process of
> maintaining
> >> updates to the API in a way users could take advantage of for the
> >> development of a personalized application environment?
> >>
> >> If something like this has already been created, where
> could I obtain
> >> access to this?
> >>
> >> How could I be notified of API changes?
> >>
> >> My formal school education was in computer networking technologies.
> >>
> >> A public number where I can be reached (not a personal telephone
> >> number), is 608-554-0030, or skype: extractedorganization
> - both voicemail only.
> >>
> >> Private skype voice, chat, and voicemail uses the name: extracted
> >>
> >> Andy Wright
> >>
> >>
> >>>
> >>> On Jan 3, 2008 12:10 AM, Jon Daley
> <plogworld at jon.limedaley.com> wrote:
> >>>> On Wed, 2 Jan 2008, Andy wrote:
> >>>>> I made a $5 donation a couple months ago:
> >>>>>
> http://myspew.com/blog/mysides-spew/software/2007/10/02/just-a-lit
> >>>>> tle-monetary-support-shows-appreciation
> >>>>>
> >>>>> That's all I could afford, but I hope it showed my appreciation.
> >>>> That's great. I don't get the notifications, so maybe
> >>>> there is more money in there than there used to be. As
> a vendor, I
> >>>> donate 10% of my revenues that get referred from lifetype. Last
> >>>> year, that only meant free hosting for LifeType, but
> this year, I
> >>>> think it will be a bunch - I'll have to look at the numbers.
> >>>>
> >>>>> I disagree with you. If the project were to end, I
> have two years
> >>>>> of PHP
> >>>>> 4 experience, among other associates. I hope that
> never happens.
> >>>>> All of you are amazing, and if their is anything more I
> can do to
> >>>>> help, please ask.
> >>>> I am not expecting the project to end, but I do expect
> >>>> support for the older versions to end as we go along. I don't
> >>>> think it would be worth your time putting lots of effort into
> >>>> supporting old versions, since the bugs get fixed in
> newer releases, etc.
> >>>> I think we are going to get a more designed task
> list for
> >>>> 2.0 soon, and so people can do stuff as they can, so
> feel free to jump in.
> >>>>
> >>>> _______________________________________________
> >>>> pLog-svn mailing list
> >>>> pLog-svn at devel.lifetype.net
> >>>> http://limedaley.com/mailman/listinfo/plog-svn
> >>>>
> >>> _______________________________________________
> >>> pLog-svn mailing list
> >>> pLog-svn at devel.lifetype.net
> >>> http://limedaley.com/mailman/listinfo/plog-svn
> >>>
> >> _______________________________________________
> >> pLog-svn mailing list
> >> pLog-svn at devel.lifetype.net
> >> http://limedaley.com/mailman/listinfo/plog-svn
> >>
> > _______________________________________________
> > pLog-svn mailing list
> > pLog-svn at devel.lifetype.net
> > http://limedaley.com/mailman/listinfo/plog-svn
> >
> _______________________________________________
> pLog-svn mailing list
> pLog-svn at devel.lifetype.net
> http://limedaley.com/mailman/listinfo/plog-svn
More information about the pLog-svn
mailing list