Page 1 of 1

scaling list addressing

PostPosted: Sun Dec 27, 2015 11:21 pm
by joejoe
Hi and thanks!

I would like to associate a username with a bunch of schedules (lists), or vice versa.

Would anyone please direct towards an efficient way to scale this type of data structure:

Code: Select all
; Format: Schedule# (Username, Schedule Name, Start Time, Interval in Seconds, Expiry).

(set 'S0 '("Username" "Feed plants" 1450754544 604800 1456197744))
(set 'S1 '("Username" "Manicure plants" 1450754544 259200 1453346544))

Or should I use this format:

Code: Select all
(set 'Username
 '(("Feed plants" 1450754544 604800 1456197744)
   ("Manicure plants" 1450754544 259200 1453346544)
  )
)

And would implicit addressing be the best way to call up the list elements?

Very much appreciate and thanks again! :)

Re: scaling list addressing

PostPosted: Mon Dec 28, 2015 7:32 am
by TedWalther
I would do it like this:

Code: Select all
(define schedules:schedules)
(define (schedules:add u)
  (let (s (sym (string "_" u)))
    (if (eval s)
      (push (args) (eval s) -1)
      (set (sym (string "_" u)) (list (args))))))

(schedules:add "user1" "Feed plants" 1450754544 604800 1456197744)
(schedules:add "user1" "Manicure plants" 1450754544 259200 1453346544)

(println (schedules "user1"))


Although this doesn't handle your "vice versa" scenario. Are all "schedules" guaranteed to have unique names?

Re: scaling list addressing

PostPosted: Thu Dec 31, 2015 3:04 am
by joejoe
Swiss Army Ted!

Greatest improvement! Thank you for this!

I like that your schedules:add method allows me to put in more list elements if needed!

I also appreciate how this method creates a nested list of usernames with their associated data.

How then would be best to use implicit indexing to call up the user schedules?

Code: Select all
(println (schedules 1 1))

returns an error:

Code: Select all
ERR: invalid parameter in function println : 1


As for the vice versa mentioned above (associating schedules with multiple users):

One thing I am considering as I further this code is to allow multiple users to access the schedules of other users.

Ok and greatest of thanks again, Ted! :0)

Re: scaling list addressing

PostPosted: Thu Dec 31, 2015 3:46 am
by TedWalther
You're welcome JoeJoe.

What I'm doing is using the red-black tree implementation, or "contexts as dictionaries". This is a common idiom in newlisp, very fast and easy.

So the question is, is a schedule unique. What do you mean by "allow another user to access the schedule". Does a schedule always belong to one and only one user?

Re: scaling list addressing

PostPosted: Thu Dec 31, 2015 4:29 am
by joejoe
TedWalther,

I appreciate the "contexts as dictionaries", thanks and it makes great sense!

So the question is, is a schedule unique.


Yes, every is schedule unique.

What do you mean by "allow another user to access the schedule".


I mean, any user could access another's schedules.

Does a schedule always belong to one and only one user?


A schedule would be created by one and only one user, and optionally shared with other users.

Big thanks TedWalther!

Re: scaling list addressing

PostPosted: Thu Dec 31, 2015 5:16 am
by TedWalther
Too vague. How would "other" users access a users schedule? What would they do with it?

Code: Select all
(define user-schedules:user-schedules)
(define (user-schedules:add u s)
  (let (nu (sym (string "_" u)))
  (if (eval nu) (push s (eval nu) -1) (set nu (list s)))
  )
)
(user-schedules:add "user1" "schedule1")

(define schedules:schedules)
(schedules "schedule1" (list 1 2 3 4))


Sounds like you want some sort of permission schemes. To really do this, you need to specify, what are the access controls you want. Which users can do what, with each schedule. Are you trying to make schedules visible and invisible on a per user basis? How is this data being accessed?

Re: scaling list addressing

PostPosted: Sat Jan 02, 2016 9:40 pm
by joejoe
Thanks again TedWalther!

TedWalther wrote:Too vague. How would "other" users access a users schedule? What would they do with it? [...]


When a user creates a schedule, that user can set that schedule to be private or public.

Users could create their own schedule or they could browse and use public schedules. Each user would have a list of schedules they have started to use, something like "My Current Schedules".

TedWalther wrote:Sounds like you want some sort of permission schemes. To really do this, you need to specify, what are the access controls you want. Which users can do what, with each schedule. Are you trying to make schedules visible and invisible on a per user basis? How is this data being accessed?


You are correct on needing permission schemes. Access controls for each schedule would be public or private. Any user can use any public schedule. A private schedule can only be viewed and used by the user who created it.

Would your suggested code still apply to this situation? Thank you again! :)

Re: scaling list addressing

PostPosted: Sat Jan 02, 2016 10:27 pm
by TedWalther
So your data model is like this:

Every schedule is unique, will have a unique name or key.

Every schedule will have a creator/owner.

Every schedule will be either public or private.

Then I propose that the schedules format is like this:

Code: Select all
;; (schedule "schedule1" "owner1" 'public 1 2 3 4 ...)


Thing is, how will the code know which user is calling? That info has to be passed into the code somehow.

Are you doing this for a school project?

Re: scaling list addressing

PostPosted: Wed Jan 06, 2016 1:15 am
by joejoe
TedWalther wrote:So your data model is like this:
Every schedule is unique, will have a unique name or key.
Every schedule will have a creator/owner.
Every schedule will be either public or private.
Then I propose that the schedules format is like this:
Code: Select all
;; (schedule "schedule1" "owner1" 'public 1 2 3 4 ...)

That makes the best sense, I see this completely, thanks Ted!

TedWalther wrote:Thing is, how will the code know which user is calling?

That info has to be passed into the code somehow.

I would guess a login system. I have installed http://newlisponrockets.com a few times.

Once logged into Rockets, I could pass the schedule info into a modified blog post in the Rockets database?

If any simpler way occurs to you, that would be superior! :)

TedWalther wrote:Are you doing this for a school project?

That would be a luxury indeed. :-)

Re: scaling list addressing

PostPosted: Wed Jan 06, 2016 8:41 am
by TedWalther
Then do this:

Code: Select all
(define (schedule:get sched usr)
  (let (s (schedule sched))
    (if s
      (if (or (= usr (s 0)) (= 'public (s 1)))
        s
        'access_denied)
      'not_found)))


Once you confirm that works, you can add more code on your own to verify that the user is valid before returning a schedule.

Just have a separate context called "users".

Re: scaling list addressing

PostPosted: Thu Jan 07, 2016 4:29 am
by joejoe
Ok big thanks Ted!

I understand the code above to test whether a script is public, and allow it if so.

Am I on a good line of thinking to have a user/pass/cookie allow private schedules to display?

Thanks again! :)

Re: scaling list addressing

PostPosted: Thu Jan 07, 2016 5:16 am
by TedWalther
joejoe wrote:Am I on a good line of thinking to have a user/pass/cookie allow private schedules to display?


Yes, as long as the cookie lets you know who the user is, and you are using SSL (https). SSL will mitigate from people snooping the connection and copying the cookie.

Re: scaling list addressing

PostPosted: Thu Jan 07, 2016 7:28 am
by joejoe
Super, got you 100% Ted!

Correct me if better,

Get going with the cookie here:

http://www.newlisp.org/syntax.cgi?code/cookie-cgi.txt

and tie it to the user form login info? Then use both to authenicate schedule access?

Thanks again!